3 ms·

I agree with the author about /etc/APK/world. APK has become my favorite package manager - so far I've had zero breakage with it, unlike apt and pacman which h

I agree with the author about /etc/APK/world. APK has become my favorite package manager - so far I've had zero breakage with it, unlike apt and pacman which have lots of sharp corners. The same can be said about Alpine Linux in general. For the last 6 months I have been experimenting with running a zero-maintenance weekly upgrade+reboot cronjob on my Alpine server. Obviously a bad idea but I just want to see how long it takes for something to break.

yjftsjthsd-h 4y ago
> Obviously a bad idea but I just want to see how long it takes for something to break. That's not quite so obvious to me. First, I don't immediately recall ever having any problems resulting from upgrading within a release (i.e. if I'm on 3.16, I don't remember `apk upgrade` ever causing a problem, but going to 3.17 might). Second, it works on other distros - the Debian family treats https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades as a totally normal supported thing to do, and I don't think Alpine is noticeably less stable than them.
- PhilipRoman 4y ago
  Oh yeah I should have clarified - I use the edge branch for this.
  - yjftsjthsd-h 4y ago
    Oh, yeah, in that case I could see it breaking eventually:) Although, it might not be an obvious breakage, either; you wouldn't notice something like upstream removing a package that you have installed (ask me how I know).
pxc 4y ago
> /etc/APK/world [FTA:] > I was very pleased to learn about apk’s /etc/apk/world. > In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else. This is fairly standard for how package managers work, afaik. From memory, Debian-based systems (in /var/lib/dpkg/status, IIRC) and Gentoo systems both work that way: constraints for the dependency solver (desired versions) are written to a persistent file in a plaintext format before the depsolver runs. In Gentoo's case, the language is also the same— the file is 'the world file' and it lives at /var/lib/portage/world. I don't have an Arch system in front of me but I imagine it also stores its package selection database in a (perhaps compressed) plaintext format like this. The novelty here is actually in encouraging users to edit the file directly by directing attention to it in the docs and by storing it under /etc, where one expects admin-facing configuration files. Definitely an improvement over the norm on Linux, imo. > apt and pacman which have lots of sharp corners I'd love to hear more about these!
- mid-kid 4y ago
  I'm not sure arch stores it in an explicit file, but pacman -Qe lists all explicitly installed packages, and anything not required will be listed in pacman -Qdt Now, it is nice that "apk del" and such automatically takes care of removing unused packages, such that you never need an "autoremove" step or similar.
- signa11 4y ago
  >> In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else. > This is fairly standard for how package managers work, afaik. i don't think there is a similar concept as that of `/etc/apk/world` in archlinux. from the article it seems that it is a list of packages that i want, and then you let `apk` run its course, installing everything (and its dependencies) mentioned therein. not sure about debian, but for gentoo `/var/lib/portage/world` see this: https://wiki.gentoo.org/wiki/Selected-packages_set_(Portage)#Editing_world_file_by_hand https://wiki.gentoo.org/wiki/Selected-packages_set_(Portage)... regarding editing that file by hand. it will be overwritten (and _aggresively_ at that)
  - jraph 4y ago
    In the Debian world, that would be the dpkg selections I think. You can mark a package as installed manually or automatically, and if it's installed automatically it can be auto removed later.
nrclark 4y ago
Alpine is great, and I have nothing bad to say about it. I'm curious though: what sharp corners have you found with apt? I've been a Debian user for 20 years and I've never had any problems relating to apt/dpkg.
- PhilipRoman 4y ago
  Never used pure Debian so I don't know how much of this is Ubuntu's fault but just today I had to fix a similar issue as described here: https://askubuntu.com/questions/1097066 https://askubuntu.com/questions/1097066 Also the solution somehow ended up uninstalling the desktop environment. Still scratching my head over that one. It wasn't my own system though.
  - pxc 4y ago
    > the solution somehow ended up uninstalling the desktop environment This is likely because the desktop environment depended on what you had to uninstall and reinstall. The package manager will normally only offer to migrate your system to states where all dependencies are resolved. If the selections you have don't have any solutions, the best it can do will be to offer solutions to (hopefully only slightly) amended selections and try to explain those alternative selections and solutions to you. This is the default behavior of aptitude when you decline a proposed solution for a package management operation; it starts computing other selections and solutions and offers them to you in turn, after it computes each. When performing dependency resolution like this, a package manager will usually consider whatever operation you're trying to do your most important preference. So if the contents of the world file or equivalent are unresolvable, when it makes amendments to your selections, the package manager 'prefers' to offer you solutions to selections that do include whatever addition or removal you've requested, but may not include some other packages that are marked as manually installed (i.e., members of your previous selection). To recover from this error non-destructively (which kinda looks like a corrupt package archive on disk), I'd first try - re-downloading both the old and new udev packages, then - manually reinstalling the old version via dpkg directly (skipping dependency checks) - manually installing the new version directly (again skipping version checks) - seeing what aptitude dist-upgrade and aptitude install -f (equivalent to apt-get install --fix-broken, but with aptitude's noisier interactive resolver) offer you But you might be able to get away with just using aptitude instead of the normal apt CLI here, and declining proposals until you see what you like. Generally speaking, using the high-level packaging tools' basic subcommands like install and uninstall in these situations will likely result in at least temporarily uninstalling a ton of stuff. For corrupt packages or depsolver brokenness, it's often better to remove the problematic package with the lower-level tools and/or bypassing dependency resolution, and then ask the high-level tool to fix the world. The naive approach of using the high-level tool to perform the uninstallation is likely to lead to those surprising proposals, because it wants to be helpful and avoid transitioning you to a state where some dependencies are unresolved— even at the cost of offering to uninstall those packages' reverse dependencies. Sometimes that tree of reverse dependencies extends all the way to the ubuntu-desktop metapackage or whatever, and BANG: you just spammed 'y' to a proposal to remove your desktop environment. Using the high-level defaults that way can also complicate future dependency resolution or just lead to the accrual of cruft by marking what are actually transitive dependencies of user package selections as manually installed. If you carelessly apt-get install some library you already have, you've just marked it as manually resolved and changed how the dependency resolver will treat that library in the future. At the end of the day, the package manager can either try to be 'smart' about satisfying your current requests by imposing them at the cost of revising your either your past selections (what dist-upgrade does) or your current selections (what install --fix-broken does), or it can just sometimes break down and tell you 'no, that set of package selections is not satisfiable'. If it does the former, when there's breakage you get 'sharp edges' (i.e., you have to reason about the package manager's dependency resolution and transition behavior to get the cleanest outcome sometimes). If it does the latter, you have to reason about your dependencies in order to amend your world file (and you might still have to reason about transition behaviors), but in some ways it shrinks the behavior puzzle you're looking at with the botched upgrade. I kind of like the more explicit failure mode, and I don't mind editing text until it makes a computer happy; that's a familiar kind of puzzle for me. I think that's part of why something like a world file is appealing to this crowd, including me. :)
zhala 4y ago
We do this regularly in production. We do biweekly container rebuilds, many running alpine and installing version unpinned packages. So far very few (if any) actual issues with that. We do of course do smoketests prior to promoting to production.

yjftsjthsd-h 4y ago

> Obviously a bad idea but I just want to see how long it takes for something to break. That's not quite so obvious to me. First, I don't immediately recall ever having any problems resulting from upgrading within a release (i.e. if I'm on 3.16, I don't remember `apk upgrade` ever causing a problem, but going to 3.17 might). Second, it works on other distros - the Debian family treats https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades as a totally normal supported thing to do, and I don't think Alpine is noticeably less stable than them.

PhilipRoman 4y ago
Oh yeah I should have clarified - I use the edge branch for this.
- yjftsjthsd-h 4y ago
  Oh, yeah, in that case I could see it breaking eventually:) Although, it might not be an obvious breakage, either; you wouldn't notice something like upstream removing a package that you have installed (ask me how I know).

pxc 4y ago

> /etc/APK/world [FTA:] > I was very pleased to learn about apk’s /etc/apk/world. > In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else. This is fairly standard for how package managers work, afaik. From memory, Debian-based systems (in /var/lib/dpkg/status, IIRC) and Gentoo systems both work that way: constraints for the dependency solver (desired versions) are written to a persistent file in a plaintext format before the depsolver runs. In Gentoo's case, the language is also the same— the file is 'the world file' and it lives at /var/lib/portage/world. I don't have an Arch system in front of me but I imagine it also stores its package selection database in a (perhaps compressed) plaintext format like this. The novelty here is actually in encouraging users to edit the file directly by directing attention to it in the docs and by storing it under /etc, where one expects admin-facing configuration files. Definitely an improvement over the norm on Linux, imo. > apt and pacman which have lots of sharp corners I'd love to hear more about these!

mid-kid 4y ago
I'm not sure arch stores it in an explicit file, but pacman -Qe lists all explicitly installed packages, and anything not required will be listed in pacman -Qdt Now, it is nice that "apk del" and such automatically takes care of removing unused packages, such that you never need an "autoremove" step or similar.
signa11 4y ago
>> In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else. > This is fairly standard for how package managers work, afaik. i don't think there is a similar concept as that of `/etc/apk/world` in archlinux. from the article it seems that it is a list of packages that i want, and then you let `apk` run its course, installing everything (and its dependencies) mentioned therein. not sure about debian, but for gentoo `/var/lib/portage/world` see this: https://wiki.gentoo.org/wiki/Selected-packages_set_(Portage)#Editing_world_file_by_hand https://wiki.gentoo.org/wiki/Selected-packages_set_(Portage)... regarding editing that file by hand. it will be overwritten (and _aggresively_ at that)
- jraph 4y ago
  In the Debian world, that would be the dpkg selections I think. You can mark a package as installed manually or automatically, and if it's installed automatically it can be auto removed later.

nrclark 4y ago

Alpine is great, and I have nothing bad to say about it. I'm curious though: what sharp corners have you found with apt? I've been a Debian user for 20 years and I've never had any problems relating to apt/dpkg.

PhilipRoman 4y ago
Never used pure Debian so I don't know how much of this is Ubuntu's fault but just today I had to fix a similar issue as described here: https://askubuntu.com/questions/1097066 https://askubuntu.com/questions/1097066 Also the solution somehow ended up uninstalling the desktop environment. Still scratching my head over that one. It wasn't my own system though.
- pxc 4y ago
  > the solution somehow ended up uninstalling the desktop environment This is likely because the desktop environment depended on what you had to uninstall and reinstall. The package manager will normally only offer to migrate your system to states where all dependencies are resolved. If the selections you have don't have any solutions, the best it can do will be to offer solutions to (hopefully only slightly) amended selections and try to explain those alternative selections and solutions to you. This is the default behavior of aptitude when you decline a proposed solution for a package management operation; it starts computing other selections and solutions and offers them to you in turn, after it computes each. When performing dependency resolution like this, a package manager will usually consider whatever operation you're trying to do your most important preference. So if the contents of the world file or equivalent are unresolvable, when it makes amendments to your selections, the package manager 'prefers' to offer you solutions to selections that do include whatever addition or removal you've requested, but may not include some other packages that are marked as manually installed (i.e., members of your previous selection). To recover from this error non-destructively (which kinda looks like a corrupt package archive on disk), I'd first try - re-downloading both the old and new udev packages, then - manually reinstalling the old version via dpkg directly (skipping dependency checks) - manually installing the new version directly (again skipping version checks) - seeing what aptitude dist-upgrade and aptitude install -f (equivalent to apt-get install --fix-broken, but with aptitude's noisier interactive resolver) offer you But you might be able to get away with just using aptitude instead of the normal apt CLI here, and declining proposals until you see what you like. Generally speaking, using the high-level packaging tools' basic subcommands like install and uninstall in these situations will likely result in at least temporarily uninstalling a ton of stuff. For corrupt packages or depsolver brokenness, it's often better to remove the problematic package with the lower-level tools and/or bypassing dependency resolution, and then ask the high-level tool to fix the world. The naive approach of using the high-level tool to perform the uninstallation is likely to lead to those surprising proposals, because it wants to be helpful and avoid transitioning you to a state where some dependencies are unresolved— even at the cost of offering to uninstall those packages' reverse dependencies. Sometimes that tree of reverse dependencies extends all the way to the ubuntu-desktop metapackage or whatever, and BANG: you just spammed 'y' to a proposal to remove your desktop environment. Using the high-level defaults that way can also complicate future dependency resolution or just lead to the accrual of cruft by marking what are actually transitive dependencies of user package selections as manually installed. If you carelessly apt-get install some library you already have, you've just marked it as manually resolved and changed how the dependency resolver will treat that library in the future. At the end of the day, the package manager can either try to be 'smart' about satisfying your current requests by imposing them at the cost of revising your either your past selections (what dist-upgrade does) or your current selections (what install --fix-broken does), or it can just sometimes break down and tell you 'no, that set of package selections is not satisfiable'. If it does the former, when there's breakage you get 'sharp edges' (i.e., you have to reason about the package manager's dependency resolution and transition behavior to get the cleanest outcome sometimes). If it does the latter, you have to reason about your dependencies in order to amend your world file (and you might still have to reason about transition behaviors), but in some ways it shrinks the behavior puzzle you're looking at with the botched upgrade. I kind of like the more explicit failure mode, and I don't mind editing text until it makes a computer happy; that's a familiar kind of puzzle for me. I think that's part of why something like a world file is appealing to this crowd, including me. :)

zhala 4y ago

We do this regularly in production. We do biweekly container rebuilds, many running alpine and installing version unpinned packages. So far very few (if any) actual issues with that. We do of course do smoketests prior to promoting to production.