feat: homebrew on image by m2Giles · Pul...
https://github.com/ublue-os/bluefin/pull/1293/
This is ready for review. I've removed brew update for those using the image based update method.
Brew is on disk and configured out of the box for UID 1000. Updates to the brew binary and the portable ruby install happen at the image level (we could consider using system ruby instead of portable ruby.
This works by creating an overalyfs at /var/home/linuxbrew. The lower layer is /usr/share/homebrew and is where the image based brew install lives. A mutable upper dir is located at /var/lib/homebrew. And the workdir is inside of /var/cache/homebrew.
For bluefin installs, there really isn't a way to force the first user to not be UID 1000. Aurora it is possible in the installer.
Additionally, there is logic to handle already existing homebrew installs. Additionally added an update timer (mutable installs only) and upgrade timer as well to have background upgrades for packages.
Concerns are that the brew formulae list is going to be tied to image updates meaning that you will need to reboot in order to be able to upgrade brew packages. But, that is an improvement over the current lack of background updates for brew
26 Replies
you will need to reboot in order to be able to upgrade brew packages.which packages specifically, the ones we preinstall? like the bluefincli stuff?
Clarification.
The git repo that brew uses for knowing if packages have been updated needs a reboot in order to get updated.
Packages can be upgraded without doing that.
The bluefin-cli stuff is a brewfile. Not installed on image
Basically
brew update is handled by image updates brew upgrade is on the booted system
This is being merged as well into bazzite testingok so let's say I'm on a 10 day old image
my brew packages would still be updated?
finishing up with my kid, I should have a few cycles tonite
I believe your brew packages will update to whatever git head will be on image. Unfortunately, Homebrew ties brew binary updates to Formula updates
GitHub
chore: split brew from default.just by m2Giles · Pull Request #278 ...
Both Bazzite and Bluefin/Aurora are adding brew on image. Because we will not want people to use the ujust commands anymore for installing brew, we should separate them from the default so the file...
Currently, we have no update mechanism running. So unless you install a new package, brew is not updating itself or packages
So basically if you are on a 10 day old image, you likely will have 10 day old binaries in brew.
If we don't want to do the overlayfs route, we can copy over the brew install, but you'll now have two brew installs on your system. One in /usr and one in /home
That would be roughly 250 MB duplicated
That could be another method, we just put the install inplace with a oneshot, then let the auto-update stuff handle it.
Then if a user wanted to remove it they could and no damage would occur if they ran brew install again/brew update
that sounds really complex and unintuitive for users.
https://github.com/ublue-os/bazzite/pull/1128#issuecomment-2113698230
we can instead just have the outputs of
ujust brew on image. And just copy it into place on first boot.
Then it would be as if we only ran ujust brew for them. This won't be duplicative of the largest component which is the portable ruby install. And would behave exactly like any other brew install
I'm leaning towards this method the more I think about it, since the overlayfs method while cool, isn't necessary and can lead to some odd situations
So, i changed it to be a copy method.
Brew will be in place by default. It will then behave exactly as if you did ujust brew. You will no longer be tied to image updates for brew itself to update. Auto update and Auto upgrade are then handled via systemd timers
This results in a duplication of 172 MB
Testing using the copy from bluefin-cli as well
That's down to 20 MB. I think that's negligablethis is looking good!!
building an iso right now.
but I'm strongly leaning this method now.
It will behave as expected. And the big items are all going to be downloaded appropiately
YOu know, this seems like the simplest way given what we have.
like, we put this in place and then we're done until systexts work
Pretty much.
If we want to install things with brew, we just fire a brewfile at their system.
yeah I agree
actually that works out because those will be like
ujust brew-k8s and so onYepp
and when they open a terminal the
ujust bluefin-cli will do the thingYepp
remind me, did we add those packages and profiles? like if we run that now what happens
In the homebrew branch.
If you run ujust bluefin-cli it will install those modern unix tools. It doesnt drop the aliases yet.
So eza and fd and rg will be there . But we haven't overwritten your bashrc yet
gotcha
man, this has to be the right way to do it
it just looks right
I think I can start working on some of that stuff soon as well.
We can use base-main for getting those binaries installed
yeah plus also
this bootc thing will probably need to be a team effort
we just finish brew now, open up the playing space
like, if we do bootc we'll have efficient downloads, it's the last thing holding us down, after that, sky is the limit
If you merge the test tools into main. I can test if we can do the bootc on 40 without negatively affecting 39.
But we'll have a complete rebuild of our processes for building bootc images
but, man if I could sysext bluefin-cli right in there, and that has brew in it already, but we can source packages from wolfi additionally (which is important because those are also my server images for those apps), that would be incredible.
ok on it
which one, noel's PR?
still draft
No. On ublue-os/main
I have the justfile suite for making ISOs there as well
on it
The plan is to put bootc on main.
Since Jason wants us to test the action more before he cuts a release, might as well do all of the testing and put bootc just straight into main