Azahara

@0x4d6165@transfem.social @piku@blahaj.zone It gets the fundamentals right without baggage. It feels built with the benefit of retrospective on literally every other package manager. It makes it easier to avoid or detect side effects, while many other package managers require explicit/extra work. Fundamentally, the way it determines what needs to be installed into the base system is much more comprehensible and inspectable: you get a single text file, the world file in /etc/apk. Anything that is installed must be there, anything that is in there must get installed, anything that isn't there must not be installed. If you're thinking "wait that sounds like declarative package management like on nixos/guix" then yes, except without a million other things those do. And yes you can modify the world file from outside apk. A package operation (add/install, or remove/uninstall) implies removing the package name from the world file, which has the side effect of removing it from your system. This implies, for the privilege of having a cleaner design, dependencies are never left behind, which as far as I know only dnf and portage do in a reasonably automatic way. The world file also has a simple syntax to specify additional package-specific constraints, like package versions, or specific hashes I believe? if you install a package file directly instead of pulling from a repository. Also repository sources (i.e.: if you want a package from alpine's edge branch in a stable install). It also understands special "aliases" related to common alternative ways to refer to a package, like pkgconf names, sonames, and commands (pc:name, so:name, and cmd:name are valid "packages" you can install!). In hindsight I should have mentioned this first because it frankly puts every other pm to shame. From the packagers' side, it also makes it easy to specify dependencies in a way that makes sense without imposing extra work to the user. It makes it easy to have packagers make, for example, bash and zsh and fish completion packages that will automatically install if and only if the relevant shell is installed. This also happens in other cases, like man pages (if you don't install man you obviously don't need those), or service files for a service manager you don't have installed (not that either alpine or chimera support more than one service manager, but think containers, those don't install the service manager and therefore don't need or get the files). These are usually solved by "recommends" fields that are kind of indiscriminate in what they install (or dont and leave the extra churn for the user to do). Besides the install and uninstall commands being add/remove (because you're adding and removing constraints to the world file, is the meaning!) everything about using apk has felt obvious and useful in a way that most other pm's haven't, even with configuration. Portage is the only PM that, in my opinion, comes close in readability and predictability, but it is gentoo's after all.

@piku@blahaj.zone@blahaj.zone @0x4d6165@transfem.social This is a pattern. Last i checked, void did not do any work at all to smooth over the edges of lacking systemd. Chimera does (i.e.: we get session dbus' instances correctly spawned, so flatpaks work no matter how you log in). Packaging stuff for either is similar in difficulty. I personally like dinit much more than either void option, and apk is probably the only reasonable traditional package manager.

i have nothing to do or look forward to until late june and i really really wish i could just sleep until then