5 ms·

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 an

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. :)
  - PhilipRoman 4y ago
    Thanks, this was an interesting writeup. Learned a few new things today.
hawski 4y ago
For me personally apt is just annoyingly slow, but dnf is much worse. I've seen how fast APK is and I feel, that my distro of choice (Void) has a package manager (XBPS) that is maybe slightly slower than it. I sometimes wonder if it is like that, because XBPS and APK were designed and built by C hackers while apt where done by system administrators maybe. With dnf/rpm I attribute it to this quirkiness I often feel diving into some of Red Hat's tech. Not trying to offend, just wondering and I acknowledge that I am biased.
- invalidator 4y ago
  > apt is just annoyingly slow A lot of that is due to aggressive use of fsync. apt tries hard to be robust against power failures when changing the system. When using it for something ephemeral (say, part of a CI workflow) you can disable fsync and let it rip. It's still not as fast as apk but it's several times faster than normal. apt-get -yq install eatmydata eatmydata apt-get -yq install (all the other things)
  - gorgoiler 4y ago
    Wow. You weren’t kidding. I tried apt install ffmpeg in a debian:sid docker container on two different docker hosts: one with slow IO (a cheap VPS with slow, contentious storage); and one with much faster, less over subscribed IO. Fast IO: 27s -> 26s with eatmydata. Basically the same. Slow IO: 280s -> 140s with eatmydata. Literally twice as fast.

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. :)
- PhilipRoman 4y ago
  Thanks, this was an interesting writeup. Learned a few new things today.

hawski 4y ago

For me personally apt is just annoyingly slow, but dnf is much worse. I've seen how fast APK is and I feel, that my distro of choice (Void) has a package manager (XBPS) that is maybe slightly slower than it. I sometimes wonder if it is like that, because XBPS and APK were designed and built by C hackers while apt where done by system administrators maybe. With dnf/rpm I attribute it to this quirkiness I often feel diving into some of Red Hat's tech. Not trying to offend, just wondering and I acknowledge that I am biased.

invalidator 4y ago
> apt is just annoyingly slow A lot of that is due to aggressive use of fsync. apt tries hard to be robust against power failures when changing the system. When using it for something ephemeral (say, part of a CI workflow) you can disable fsync and let it rip. It's still not as fast as apk but it's several times faster than normal. apt-get -yq install eatmydata eatmydata apt-get -yq install (all the other things)
- gorgoiler 4y ago
  Wow. You weren’t kidding. I tried apt install ffmpeg in a debian:sid docker container on two different docker hosts: one with slow IO (a cheap VPS with slow, contentious storage); and one with much faster, less over subscribed IO. Fast IO: 27s -> 26s with eatmydata. Basically the same. Slow IO: 280s -> 140s with eatmydata. Literally twice as fast.