Apt-bundle: brew bundle for apt | Hacker News Reader

Apt-bundle: brew bundle for apt

github.com

39 pointssadeshmukh32 comments

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).

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/

Or just homebrew on Linux?

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.

"let's allow any user process to modify my binaries" is not something to be proud of...

https://xkcd.com/1200/

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.

Can you give some examples?

Updating all of your installed packages when you ask it to install a new one. This is so utterly ridiculous that it singlehandedly nade me stop using brew. I can't imagine what other bad decisions they make if this is what they thought was a good one.

Another fact is that it's basically like AUR, with little to no oversight. If AUR had malware then just imagine how much malware is there in brew recipes.

They also didn't use cryptographic signing for the longest time, they did get some shit for that.

There were more, can't remember now.

One other thing that seriously annoys me is the automated closure of reported issues after they get no response for a while. So I reported maybe 3 bugs and then I stopped altogether, because why would you waste your time on a project that doesn't respect it? All these bugs were actual full blown bug reports, well written and researched. I can't but think that projects that close issues like that are made to look better than they are.

Also, you guys remember when its author ranted about not having gotten a job at Apple? I always thought they cared about the prestige of that project more than the actual project, based on the level of security shortcomings. Brew has that serious amateurish taste to it.

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.

Absolutely this. I can't but think that brew is an extension of author(s) ego. Remember that essay about them failing to get a job at Apple?

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.

This whole thread was fiction and was missing this: "/s". I don't believe any of what I proposed above would be a good idea. Didn't think it would woosh and couldn't help myself doubling down when (if?) it did. Sorry for trolling.

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

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.

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?

Probably nothing other than the fact that you don't have to maintain it and have less worries about portability, like most command line utilities.

Still, can you share your script?

Reply on news.ycombinator.com