[HN Gopher] In Praise of Alpine and APK
       ___________________________________________________________________
        
       In Praise of Alpine and APK
        
       Author : zdw
       Score  : 54 points
       Date   : 2023-02-20 17:37 UTC (5 hours ago)
        
 (HTM) web link (whynothugo.nl)
 (TXT) w3m dump (whynothugo.nl)
        
       | ed25519FUUU wrote:
       | > _The first is that using a different libc helps finds bugs in
       | programs that assume that every system uses glibc._
       | 
       | I praise the author for taking this work upon himself. As for me
       | I don't want anything to do with being a bug canary for other
       | developers. I'll take time tested and stable thank you.
        
       | PhilipRoman wrote:
       | 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.
        
         | pxc wrote:
         | > /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!
        
         | yjftsjthsd-h wrote:
         | > 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 as a totally normal
         | supported thing to do, and I don't think Alpine is noticeably
         | less stable than them.
        
           | PhilipRoman wrote:
           | Oh yeah I should have clarified - I use the edge branch for
           | this.
        
             | yjftsjthsd-h wrote:
             | 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).
        
         | nrclark wrote:
         | 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 wrote:
           | 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 Also
           | the solution somehow ended up uninstalling the desktop
           | environment. Still scratching my head over that one. It
           | wasn't my own system though.
        
           | hawski wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2023-02-20 23:00 UTC)