9 ms·

I'm excited to see someone is working on this. I have considered switching from Arch to Sid in the past, mainly so that I could run the same OS on all computers

I'm excited to see someone is working on this. I have considered switching from Arch to Sid in the past, mainly so that I could run the same OS on all computers and because I like the DFSG. Two things have stopped me: * It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I'm sure a dedicated enough user can learn to use the Debian packaging software proficiently, but it's a huge barrier to entry when I have something as easy as Arch's PKGBUILD syntax at my disposal. It looks like this project is interested in solving this problem: rather than using Debian's packaging tools for the DUR, it actually appears to literally be using makepkg with a Debian conversion script running on top. [1] * The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. Debian's systemd install currently still supports [2] and uses init scripts and update-rc.d, the very thing unit files were supposed to take us beyond. In fact, a pretty minimal Debian installation I have on a server has 14 init scripts, while my Arch install doesn't even have an /etc/init.d directory! On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. [1] https://docs.hunterwittenborn.com/makedeb/makedeb/intro https://docs.hunterwittenborn.com/makedeb/makedeb/intro [2] https://wiki.debian.org/Teams/pkg-systemd/Integration https://wiki.debian.org/Teams/pkg-systemd/Integration

spinax 5y ago
I agree, RPM is similarly just as easy amongst others who all sort of stick to a single control file design. This exact DEB ergonomic pain of files all over the place keeps me at arms length, it's clunky (to me) and the build process weirds me out with how many variations on tools used to get the same result. It's backwards compatible as all get go, I'll give you that.
zxzax 5y ago
>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though. Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros. [0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/ https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...
- bscphil 5y ago
  Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.
  - zxzax 5y ago
    Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
    - corndoge 5y ago
      What package and how complex is it?
      - zxzax 5y ago
        I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
        namibj 5y ago
        makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
        zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.
thayne 5y ago
> The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. I haven't used plain Debian, but this has been my experience with Ubuntu. Almost all the problems I've run into with systemd have been because of an interaction with init.d scripts that should be systemd units, or similar. My biggest complaint is that while systemd-resolved is supposed to be optional, on Ubuntu it is practically impossible to fully disable without breaking things, and disabling is officially "unsupported". On archlinux, if you want to use dnsmasq instead it is just a matter of disabling one service and enabling the other.
- mst 5y ago
  This is actually something that keeps tempting me to try arch, since it having gone all-in on systemd early on would hopefully give me a more 'native' systemd experience and help me figure out which of my gripes are with systemd and which of them are with how-$distro-added-systemd. Thing is, I'd only want such an install for playing around with occasionally and as the argument upthread makes pretty clear, "doing a bulk upgrade occasionally" is something that really isn't regarded as a sensible way to run arch.
  - bscphil 5y ago
    I do my upgrades every few weeks, for what it's worth, and I've had the same Arch install since 2013. The size of the upgrade should very rarely have any effect on whether it succeeds; you're just more likely to have missed some major changes if you're upgrading without checking the latest news from the website. Partial updates are also unsupported, and in my experience that's the most common way people break things.
throwawaaarrgh 5y ago
> On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. This should be expected though. Debian has been around a lot longer and is depended on by more of the Linux world. Complexity is a natural outcome of more stakeholder requirements (more stakeholders = more requirements = more complexity). I won't get into the systemd holy war, but suffice to say that comparing the architecture of init scripts vs systemd is like comparing the design of a bicycle to a car. One most definitely is more complex than the other, but whether that's a good thing or not depends on what you want to do with it.
- kijin 5y ago
  It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle. I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time. If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.
  - andrewshadura 5y ago
    In fact, init scripts are only used by systemd when there are no corresponding native unit files.
    - kijin 5y ago
      A lot of debian packages supply both systemd unit files and init scripts. You can use either to step on the other's foot.
      - andrewshadura 5y ago
        As I said, init scripts are only used if there's no unit file. If there's a systemd unit, the init script is ignored.
mjw1007 5y ago
The inconvenience goes further than building in the first place. If I want to try running a Debian package with an experimental patch as a one-off, I haven't found it too hard to build my own version. But AFAIK there's nothing that helps me manage the necessary work to rebuild with the same patch when a new distribution version comes along. Do source-based distributions have a good solution for this?
- andrewshadura 5y ago
  If you use Git, you just run git merge. If not, uupdate gives a good enough result for further fine tuning.
nextlevelwizard 5y ago
This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was linked against the old one. Only "work around" I found was to symlink the current lib to the old's path. Second time I just just running bog standard fetch & update. Then I rebooted as is normal after you update and it no longer booted. Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.
- spinax 5y ago
  > Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.
  - hjek 5y ago
    > This laptop I'm typing from now was installed 2014-07-06, It goes beyond anecdotal evidence. I mean, if you look at the Arch news feed[0], there are a good few updates since then that are labelled "requires manual intervention". I like Arch and it's great they're posting those notices, but I don't think it can be claimed that upgrading an on-the-edge system is always problem free. [0] https://archlinux.org/news/ https://archlinux.org/news/
    - spinax 5y ago
      This is part of the agreement for using Arch, it's not a system you can ignore, you must actually pay attention to these news items. The upgrade tool I use actually shows new news to you front and center when performing an upgrade so you're blatantly aware that you have to follow instructions. Those are not "problems", they are "following instructions to keep up with changes." If you wand a distro to just ignore and hope it all goes well, Arch is not for you. Never was.

spinax 5y ago

I agree, RPM is similarly just as easy amongst others who all sort of stick to a single control file design. This exact DEB ergonomic pain of files all over the place keeps me at arms length, it's clunky (to me) and the build process weirds me out with how many variations on tools used to get the same result. It's backwards compatible as all get go, I'll give you that.

zxzax 5y ago

>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though. Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros. [0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/ https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...

bscphil 5y ago
Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.
- zxzax 5y ago
  Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
  - corndoge 5y ago
    What package and how complex is it?
    - zxzax 5y ago
      I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
      - namibj 5y ago
        makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
        zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.

thayne 5y ago

> The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. I haven't used plain Debian, but this has been my experience with Ubuntu. Almost all the problems I've run into with systemd have been because of an interaction with init.d scripts that should be systemd units, or similar. My biggest complaint is that while systemd-resolved is supposed to be optional, on Ubuntu it is practically impossible to fully disable without breaking things, and disabling is officially "unsupported". On archlinux, if you want to use dnsmasq instead it is just a matter of disabling one service and enabling the other.

mst 5y ago
This is actually something that keeps tempting me to try arch, since it having gone all-in on systemd early on would hopefully give me a more 'native' systemd experience and help me figure out which of my gripes are with systemd and which of them are with how-$distro-added-systemd. Thing is, I'd only want such an install for playing around with occasionally and as the argument upthread makes pretty clear, "doing a bulk upgrade occasionally" is something that really isn't regarded as a sensible way to run arch.
- bscphil 5y ago
  I do my upgrades every few weeks, for what it's worth, and I've had the same Arch install since 2013. The size of the upgrade should very rarely have any effect on whether it succeeds; you're just more likely to have missed some major changes if you're upgrading without checking the latest news from the website. Partial updates are also unsupported, and in my experience that's the most common way people break things.

throwawaaarrgh 5y ago

> On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. This should be expected though. Debian has been around a lot longer and is depended on by more of the Linux world. Complexity is a natural outcome of more stakeholder requirements (more stakeholders = more requirements = more complexity). I won't get into the systemd holy war, but suffice to say that comparing the architecture of init scripts vs systemd is like comparing the design of a bicycle to a car. One most definitely is more complex than the other, but whether that's a good thing or not depends on what you want to do with it.

kijin 5y ago
It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle. I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time. If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.
- andrewshadura 5y ago
  In fact, init scripts are only used by systemd when there are no corresponding native unit files.
  - kijin 5y ago
    A lot of debian packages supply both systemd unit files and init scripts. You can use either to step on the other's foot.
    - andrewshadura 5y ago
      As I said, init scripts are only used if there's no unit file. If there's a systemd unit, the init script is ignored.

mjw1007 5y ago

The inconvenience goes further than building in the first place. If I want to try running a Debian package with an experimental patch as a one-off, I haven't found it too hard to build my own version. But AFAIK there's nothing that helps me manage the necessary work to rebuild with the same patch when a new distribution version comes along. Do source-based distributions have a good solution for this?

andrewshadura 5y ago
If you use Git, you just run git merge. If not, uupdate gives a good enough result for further fine tuning.

nextlevelwizard 5y ago

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was linked against the old one. Only "work around" I found was to symlink the current lib to the old's path. Second time I just just running bog standard fetch & update. Then I rebooted as is normal after you update and it no longer booted. Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.

spinax 5y ago
> Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.
- hjek 5y ago
  > This laptop I'm typing from now was installed 2014-07-06, It goes beyond anecdotal evidence. I mean, if you look at the Arch news feed[0], there are a good few updates since then that are labelled "requires manual intervention". I like Arch and it's great they're posting those notices, but I don't think it can be claimed that upgrading an on-the-edge system is always problem free. [0] https://archlinux.org/news/ https://archlinux.org/news/
  - spinax 5y ago
    This is part of the agreement for using Arch, it's not a system you can ignore, you must actually pay attention to these news items. The upgrade tool I use actually shows new news to you front and center when performing an upgrade so you're blatantly aware that you have to follow instructions. Those are not "problems", they are "following instructions to keep up with changes." If you wand a distro to just ignore and hope it all goes well, Arch is not for you. Never was.