Brew got one thing right that no Linux package manager seems to emulate: it doesn't require root for normal operations and even goes so far as to error out if running as root (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).
In multi-user mode, Nix uses dedicated build users to write to the store. There is also single-user mode, but that also doesn't require a world-writable store.
There is also conda/mamba/pixi/etc. (anything in the conda-forge ecosystem) that can be used without root. Then there are Guix and nix, which (mostly) require to be set up by someone with root privileges, but which then allow unprivileged users to install packages for themselves. I think I have even used emerge rootless-ly at some point a few years ago.
Brew is so full of Linux/OSS/GNU anti-patterns that I can't wrap my head how did it ever managed to receive so much adoption. I guess macOS people are way more ignorant about things that made Linux/OSS what it is.
Looking at internal/commands/install.go, it only installs new packages, but doesn't uninstall removed ones. That's the biggest benefit of Brew bundle gone.
apk uses a similar approach by default, and I think it's a wonderful way for a package manager to operate.
Basically, /etc/apk/world keeps a list of explicitly installed packages.
When you manually install a package, it's added to this list, when you manually remove a package, it's removed from the list.
Installation and upgrading (and "fixing) merely ensures that those packages and their dependencies are installed, no more, no less. This also automatically cleans up stale, unused dependencies.
It's a lovely way to get deterministic results. You can just back-up that world file, or copy it to another machine and get the exact same installation.
The ppa directive hints that this is intended for Ubuntu because otherwise installing PPAs is a great way to break a non Ubuntu distro.
The deb directive uses the old and soon to be deprecated .list file extension. DEB822 format is the replacement.
The key directive adds the key as globally trusted for all repos instead of locking it to a specific repo as recommended by Debian. I think this is required under the new DEB822 repo format.
Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
> Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
Good luck share the progress and let us know how it goes. Is it similar to nix? but from what I can feel, is intending to be simpler?
One key insight is that bundles are really sets of packages and that what we're doing when we bundle things is really just set join operations. Imagine the possibilities if we implement arbitrary set operations. So a bunch is defined as a set of bundles (which can themselves be down to a single package of course) and the declarations in the Aptbundlefile translates under the hood to references and set operations. This is not only declarative, it's also purely functional. Still working on if arbitrary set operations should be accessible by DSL in Aptbundlefile or if that should be left to tools building on top of intermediary API. So yeah, parallels to Nix for sure but it's still apt packages, not building the world from source.
What shell scripts would help here? I love me some shell scripting but always reached for debfoster before falling in love with Pac-Man's `-Qe` and `-Qt`
Edit: oh this aptfile doesn't do the one thing I actually use brew bundle for: cleaning up the mess of leftover packages
Brew got one thing right that no Linux package manager seems to emulate: it doesn't require root for normal operations and even goes so far as to error out if running as root (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).
"let's allow any user process to modify my binaries" is not something to be proud of...
https://xkcd.com/1200/
It needs world-writtable /opt/homebrew, so I guess a Linux equivalent would be Nix (which IIUC requires writable /nix).
For something that only uses your home folder, I recommend checking out mise https://mise.jdx.dev/
In multi-user mode, Nix uses dedicated build users to write to the store. There is also single-user mode, but that also doesn't require a world-writable store.
Or just homebrew on Linux?
Brew _is_ a linux package manager.
There is also conda/mamba/pixi/etc. (anything in the conda-forge ecosystem) that can be used without root. Then there are Guix and nix, which (mostly) require to be set up by someone with root privileges, but which then allow unprivileged users to install packages for themselves. I think I have even used emerge rootless-ly at some point a few years ago.
Brew is so full of Linux/OSS/GNU anti-patterns that I can't wrap my head how did it ever managed to receive so much adoption. I guess macOS people are way more ignorant about things that made Linux/OSS what it is.
It doesn't help that the project authors shut down any conversation about flaws.
They're so convinced that their way is right and essentially stick their fingers in their ears when anyone raises concerns.
Unfortunately cargo culting is a thing.
I say this as a macOS user.
Fortunately alternatives like MacPorts exist.
1 reply →
Can you give some examples?
1 reply →
Looking at internal/commands/install.go, it only installs new packages, but doesn't uninstall removed ones. That's the biggest benefit of Brew bundle gone.
BTW how much of it is vibe coded?
apk uses a similar approach by default, and I think it's a wonderful way for a package manager to operate.
Basically, /etc/apk/world keeps a list of explicitly installed packages.
When you manually install a package, it's added to this list, when you manually remove a package, it's removed from the list.
Installation and upgrading (and "fixing) merely ensures that those packages and their dependencies are installed, no more, no less. This also automatically cleans up stale, unused dependencies.
It's a lovely way to get deterministic results. You can just back-up that world file, or copy it to another machine and get the exact same installation.
apt-mark manual has allowed the same functionality in apt since forever and probably inspired apk's copy of it :)
I hate the Aptfile format after looking at it.
The ppa directive hints that this is intended for Ubuntu because otherwise installing PPAs is a great way to break a non Ubuntu distro.
The deb directive uses the old and soon to be deprecated .list file extension. DEB822 format is the replacement.
The key directive adds the key as globally trusted for all repos instead of locking it to a specific repo as recommended by Debian. I think this is required under the new DEB822 repo format.
Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
> Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
Good luck share the progress and let us know how it goes. Is it similar to nix? but from what I can feel, is intending to be simpler?
One key insight is that bundles are really sets of packages and that what we're doing when we bundle things is really just set join operations. Imagine the possibilities if we implement arbitrary set operations. So a bunch is defined as a set of bundles (which can themselves be down to a single package of course) and the declarations in the Aptbundlefile translates under the hood to references and set operations. This is not only declarative, it's also purely functional. Still working on if arbitrary set operations should be accessible by DSL in Aptbundlefile or if that should be left to tools building on top of intermediary API. So yeah, parallels to Nix for sure but it's still apt packages, not building the world from source.
1 reply →
aconfmgr[https://github.com/CyberShadow/aconfmgr] is a kinda similar project for pacman-based distributions.
The difference is that it strives to track all non-user files, (not just packages, and especially /etc), but you can adopt it partially.
So, this is better than `dpkg --get-selections/--set-selections`? Oh, because it's partial?
This appears to be a Show HN.
Put in my mise.toml :)
man the things people come up with to avoid writing bash scripts
Given your username, do you have the same reaction to bundler?
What shell scripts would help here? I love me some shell scripting but always reached for debfoster before falling in love with Pac-Man's `-Qe` and `-Qt`
Edit: oh this aptfile doesn't do the one thing I actually use brew bundle for: cleaning up the mess of leftover packages
I've been loving the Alpine Package Keeper, especially easily maintaining desired packaging state in /etc/apk/world
https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper#Worl...
What is this tool solving that I can't do with apt+bash already?
1 reply →
I wish I could upvote this more than once.
I am having a hard time seeing that the install config isn't just basically bash with some aliases...but I still haven't had my second cup of coffee.