9 ms·

The packaging nightmare is why I left Debian and Ubuntu for Arch. I now maintain multiple packages in the AUR with relative ease, and see how easily other maint

by gitweb 6y ago

The packaging nightmare is why I left Debian and Ubuntu for Arch. I now maintain multiple packages in the AUR with relative ease, and see how easily other maintainers manage multiple packages like Kubernetes without issue, but if it was using Deb packages it would be a full-time job.

viraptor 6y ago
I'm not sure this is a fair comparison. AUR has next to no rules. You could just as easily maintain a PPA. As described in the article, the package is available via Debian-testing.
- loopz 6y ago
  Arch/Manjaro is often praised as simpler, more powerful etc., but there are also complaints about instability. Mint has several QA links: upstream, debian, Ubuntu, Mint. With Mint sanitizing the corporate influence, ie. snap being off by default. I don't need bleeding edge, just stable desktop. So I've found my optimum in Mint, though nothing is perfect. Vendoring is shifting focus back to individual projects though. K8s could almost replace an OS in many regards. It is made to be modular, but only within its own framework. So it is changing the way software is run, similarly to initd and systemd. Such systems as we've seen, tend to "take over" and not be made to be part of and integrate well from inside an OS. Vendoring is really old practice, but also makes testing and support simpler for upstream. We all know the dynamic approach tend to be more unchanging, or associated with several circles of dependency hells. It's just different end goals for software development and deployment, that affect how software is distributed. Kind of similar to touted goals of JEE of java fame, which also is too monolithic to integrate well within complex systems.
- gitweb 6y ago
  I encourage everyone to go evaluate building and submitting a package using the AUR vs Launchpad (PPA). I worked at Canonical and would never go back to Dpkg. I recommend users try it out themselves and see how much easier and cleaner the PKGBUILD approach is. AUR does have a process to rate, flag and comment on packages. It is also much easier to review the installation script using PKGBUILD. There are a lot of high quality packages in the AUR but you should review everything you install unofficially, just like installing packages from a PPA.
konjin 6y ago
The packaging nightmare also means that when you stand up a system it won't need upgrades for a decade Leave an arch system without an upgrade for a month and you're playing Russian roulette.
- gravypod 6y ago
  It will need upgrades for those decades you're just hoping someone remembers how to apply them 9years after they're I'm wide spread adoption.
  - konjin 6y ago
    No, it will need security updates. Which Debian stable provides for seven years currently.
- jchw 6y ago
  People say this all the time but it isn’t true. Occasionally a package will require manual intervention to update properly. The manual intervention steps are generally pretty easy and documented on the Arch homepage, so if you haven’t updated in a while and are concerned, all you really have to do is check the homepage. But I don’t even do that. I just pacman -Syu and check if it failed. For the past few years this has worked out just fine. Most of the packages, I don’t even have installed, so I hardly ever hit a manual intervention step. Of course, Debian doesn’t require manual intervention for most updates, but it also isn’t rolling release. If you want packages that are actually recent you have to sit on Sid, which is a lot less stable than Arch. And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck. Some of that isn’t Debian’s fault, but whereas on Arch major, breaking package changes are rare but irregular, on Debian they tend to hit you simultaneously in one major upgrade. For home machines, I definitely prefer an occasional manual intervention and continuous fixes over major breakages every couple years where I often just give up and reinstall from scratch. That said I use Arch a lot less nowadays as I’ve moved onto NixOS. Nix is clearly headed somewhere new, though it remains to be seen if the complexity of the approach is actually maintainable. If I want to make an idiomatic Arch package, it’s usually easy: PKGBUILDs are intuitive and simple. Nix is much the same for most stuff, especially since most of the boilerplate for various build systems has been automated; though for a program as complex as Kubernetes its a nightmare, to be sure. For Dpkg though, it seems like so much complexity, and I don’t think I ever really had a good experience. And honestly, I have no idea how to make an RPM package anymore.
barumi 6y ago
> The packaging nightmare is why I left Debian and Ubuntu for Arch. I find this comment odd and highly dubious. There is absolutely nothing wrong with Debian's packaging system. At most, some individual packages could have been packaged differently, which is arguably a matter of personal taste. Normally, everything just works, and works very well. Either you shed some additional light on your personal struggles with Debian's packaging, which you did not do at all, or I have to scratch off your baseless assertion as a kin of someone on the internet shouting at clouds.
- jchw 6y ago
  It is a recurring theme that whenever Arch proponents mention that they don't like Debian packaging, there is a frustrated reaction to it. But I don't understand what people want to hear; there's clearly a reason why people would choose Debian over Arch, Arch users say packaging is a big part of it, and it seems like nobody can accept that this is right. I can at least tell you that people don't choose Arch over Debian for the installation experience. :)
  - bawolff 6y ago
    The parent was a bit aggressive, but i think asking why the first poster likes arch packages better than debian is a fair question, since that's the interesting part.
  - lloeki 6y ago
    > I can at least tell you that people don't choose Arch over Debian for the installation experience Well, I do (sample of one). The Arch installation has been streamlined a lot. Now it’s all about 0) boot the image (cd, usb, PXE), which is actually an Arch install a) creating your filesystem (pick you poison), and mounting it b) telling pacman to install base, base-devel, and a bootloader on the target fs c) installing and configuring the bootloader d) rebooting Done. d-i barely takes care of that for you, it’s “just” wrapping it behind a UI (which is sort of useful, sure saves one from reading docs, but has been an annoying abstraction/obfuscation/magic layer for me more often than not). The remainder (setting up X/Wayland/whatever is no different on Debian than on Arch, as d-i does not help much.
csande17 6y ago
Say what you will about Gentoo, but I've actually really liked making some small packages for personal use. It's the closest system I've seen to just writing down the steps you'd normally take to compile the software manually.
- 1_player 6y ago
  That how Arch Linux packages work. Just a shell file with some metadata
cbmuser 6y ago
Arch doesn’t have to support multiple architectures and releases. Also, Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages. Also, Debian separates packages into runtime and development libraries, another thing Arch doesn’t do either.
- gitweb 6y ago
  This is incorrect
  - Foxboron 6y ago
    How is the previous statement incorrect?
    - gitweb 6y ago
      > Also, Debian separates packages into runtime and development libraries, another thing Arch doesn’t do either. Arch definitely has separate packages for runtime and development libraries. It doesn't have as many, but they exist and can be found by simply searching for `-dev`. > Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages Arch has `any` and then architecture specific packages: https://wiki.archlinux.org/index.php/Arch_package_guidelines#Architectures https://wiki.archlinux.org/index.php/Arch_package_guidelines... > Arch doesn’t have to support multiple architectures and releases https://wiki.archlinux.org/index.php/32-bit_package_guidelines https://wiki.archlinux.org/index.php/32-bit_package_guidelin... There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point.
      - Foxboron 6y ago
        > Arch definitely has separate packages for runtime and development libraries. It doesn't have as many, but they exist and can be found by simply searching for `-dev`. They are an exception to the rule, where the benefits outweights the negatives. It's been done to ensure we have smaller container images, or if the maintaine thinks it makes sense. But as a rule, we do not care while debian does. >Arch has `any` and then architecture specific packages: How is the `any` arch related to package splitting? >https://wiki.archlinux.org/index.php/32-bit_package_guidelin https://wiki.archlinux.org/index.php/32-bit_package_guidelin... > There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point. Those package guidelines exist, but are dated and not used by us, the packagers. Arch ARM and 32bit are also seperate distirbutions that isn't affiliated with the 64bit Arch Linux distribution.

by gitweb 6y ago

viraptor 6y ago

I'm not sure this is a fair comparison. AUR has next to no rules. You could just as easily maintain a PPA. As described in the article, the package is available via Debian-testing.

loopz 6y ago
Arch/Manjaro is often praised as simpler, more powerful etc., but there are also complaints about instability. Mint has several QA links: upstream, debian, Ubuntu, Mint. With Mint sanitizing the corporate influence, ie. snap being off by default. I don't need bleeding edge, just stable desktop. So I've found my optimum in Mint, though nothing is perfect. Vendoring is shifting focus back to individual projects though. K8s could almost replace an OS in many regards. It is made to be modular, but only within its own framework. So it is changing the way software is run, similarly to initd and systemd. Such systems as we've seen, tend to "take over" and not be made to be part of and integrate well from inside an OS. Vendoring is really old practice, but also makes testing and support simpler for upstream. We all know the dynamic approach tend to be more unchanging, or associated with several circles of dependency hells. It's just different end goals for software development and deployment, that affect how software is distributed. Kind of similar to touted goals of JEE of java fame, which also is too monolithic to integrate well within complex systems.
gitweb 6y ago
I encourage everyone to go evaluate building and submitting a package using the AUR vs Launchpad (PPA). I worked at Canonical and would never go back to Dpkg. I recommend users try it out themselves and see how much easier and cleaner the PKGBUILD approach is. AUR does have a process to rate, flag and comment on packages. It is also much easier to review the installation script using PKGBUILD. There are a lot of high quality packages in the AUR but you should review everything you install unofficially, just like installing packages from a PPA.

konjin 6y ago

The packaging nightmare also means that when you stand up a system it won't need upgrades for a decade Leave an arch system without an upgrade for a month and you're playing Russian roulette.

gravypod 6y ago
It will need upgrades for those decades you're just hoping someone remembers how to apply them 9years after they're I'm wide spread adoption.
- konjin 6y ago
  No, it will need security updates. Which Debian stable provides for seven years currently.
jchw 6y ago
People say this all the time but it isn’t true. Occasionally a package will require manual intervention to update properly. The manual intervention steps are generally pretty easy and documented on the Arch homepage, so if you haven’t updated in a while and are concerned, all you really have to do is check the homepage. But I don’t even do that. I just pacman -Syu and check if it failed. For the past few years this has worked out just fine. Most of the packages, I don’t even have installed, so I hardly ever hit a manual intervention step. Of course, Debian doesn’t require manual intervention for most updates, but it also isn’t rolling release. If you want packages that are actually recent you have to sit on Sid, which is a lot less stable than Arch. And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck. Some of that isn’t Debian’s fault, but whereas on Arch major, breaking package changes are rare but irregular, on Debian they tend to hit you simultaneously in one major upgrade. For home machines, I definitely prefer an occasional manual intervention and continuous fixes over major breakages every couple years where I often just give up and reinstall from scratch. That said I use Arch a lot less nowadays as I’ve moved onto NixOS. Nix is clearly headed somewhere new, though it remains to be seen if the complexity of the approach is actually maintainable. If I want to make an idiomatic Arch package, it’s usually easy: PKGBUILDs are intuitive and simple. Nix is much the same for most stuff, especially since most of the boilerplate for various build systems has been automated; though for a program as complex as Kubernetes its a nightmare, to be sure. For Dpkg though, it seems like so much complexity, and I don’t think I ever really had a good experience. And honestly, I have no idea how to make an RPM package anymore.

barumi 6y ago

> The packaging nightmare is why I left Debian and Ubuntu for Arch. I find this comment odd and highly dubious. There is absolutely nothing wrong with Debian's packaging system. At most, some individual packages could have been packaged differently, which is arguably a matter of personal taste. Normally, everything just works, and works very well. Either you shed some additional light on your personal struggles with Debian's packaging, which you did not do at all, or I have to scratch off your baseless assertion as a kin of someone on the internet shouting at clouds.

jchw 6y ago
It is a recurring theme that whenever Arch proponents mention that they don't like Debian packaging, there is a frustrated reaction to it. But I don't understand what people want to hear; there's clearly a reason why people would choose Debian over Arch, Arch users say packaging is a big part of it, and it seems like nobody can accept that this is right. I can at least tell you that people don't choose Arch over Debian for the installation experience. :)
- bawolff 6y ago
  The parent was a bit aggressive, but i think asking why the first poster likes arch packages better than debian is a fair question, since that's the interesting part.
- lloeki 6y ago
  > I can at least tell you that people don't choose Arch over Debian for the installation experience Well, I do (sample of one). The Arch installation has been streamlined a lot. Now it’s all about 0) boot the image (cd, usb, PXE), which is actually an Arch install a) creating your filesystem (pick you poison), and mounting it b) telling pacman to install base, base-devel, and a bootloader on the target fs c) installing and configuring the bootloader d) rebooting Done. d-i barely takes care of that for you, it’s “just” wrapping it behind a UI (which is sort of useful, sure saves one from reading docs, but has been an annoying abstraction/obfuscation/magic layer for me more often than not). The remainder (setting up X/Wayland/whatever is no different on Debian than on Arch, as d-i does not help much.

csande17 6y ago

Say what you will about Gentoo, but I've actually really liked making some small packages for personal use. It's the closest system I've seen to just writing down the steps you'd normally take to compile the software manually.

1_player 6y ago
That how Arch Linux packages work. Just a shell file with some metadata

cbmuser 6y ago

Arch doesn’t have to support multiple architectures and releases. Also, Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages. Also, Debian separates packages into runtime and development libraries, another thing Arch doesn’t do either.

gitweb 6y ago
This is incorrect
- Foxboron 6y ago
  How is the previous statement incorrect?
  - gitweb 6y ago
    > Also, Debian separates packages into runtime and development libraries, another thing Arch doesn’t do either. Arch definitely has separate packages for runtime and development libraries. It doesn't have as many, but they exist and can be found by simply searching for `-dev`. > Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages Arch has `any` and then architecture specific packages: https://wiki.archlinux.org/index.php/Arch_package_guidelines#Architectures https://wiki.archlinux.org/index.php/Arch_package_guidelines... > Arch doesn’t have to support multiple architectures and releases https://wiki.archlinux.org/index.php/32-bit_package_guidelines https://wiki.archlinux.org/index.php/32-bit_package_guidelin... There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point.
    - Foxboron 6y ago
      > Arch definitely has separate packages for runtime and development libraries. It doesn't have as many, but they exist and can be found by simply searching for `-dev`. They are an exception to the rule, where the benefits outweights the negatives. It's been done to ensure we have smaller container images, or if the maintaine thinks it makes sense. But as a rule, we do not care while debian does. >Arch has `any` and then architecture specific packages: How is the `any` arch related to package splitting? >https://wiki.archlinux.org/index.php/32-bit_package_guidelin https://wiki.archlinux.org/index.php/32-bit_package_guidelin... > There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point. Those package guidelines exist, but are dated and not used by us, the packagers. Arch ARM and 32bit are also seperate distirbutions that isn't affiliated with the 64bit Arch Linux distribution.