J@Robert (p5) you showed an action that installed podman in CI the other day, I wonder if we can use some of brew's CI features to get what we want in the image.
J
FInstalling podman with brew inside GitHub action doesn't work due to this issue
https://github.com/containers/podman/issues/22152
https://github.com/containers/podman/issues/22152
GitHub
Issue Description https://github.com/skupperproject/skupper-router/actions/runs/8392267222/job/23044730533 ==> Downloading https://ghcr.io/v2/homebrew/core/podman/manifests/5.0.0-1 ... ==> Po...
Fwhile issue is closed, it's still reproducible
Fnot directly connected with your intended question, but just adding a note that some issue like this can potentially happen
Jyeah I'm not thinking for complex services either, but more every day tools
MOkay, I think is doable right now.
The CLI and non-interactive flags will be helpful. So long as we are inside a podman container or docker container we can run the installer script as root
The CLI and non-interactive flags will be helpful. So long as we are inside a podman container or docker container we can run the installer script as root
Mand we can chown the dir at the end to uid:gid 1000:1000
so before we have user name
so before we have user name
Jooooh
Mnow, trying to figure out how to workaround the /home location
Msince normally things coming from the image should be immutable in /usr
JI'm pretty sure the home location is required isn't it?
Mso my initial thought is we install via a bind mount from /usr/share/homebrew or something. And then have an overlay mount at boot time to make the location mutable and the overlay comes from something /var/lib/homebrew
J
Myes, we want to use the default location so users don't have to recompile anyway
Jnod
Mso it's how do we have it in a proper location while still working around the confines of rpm-ostree
JJstill not sure why we don't show up here
Mit uses lib_release or something like that and we show up as Fedora
M
Mbind mount inside of build container works. So setting up a service file to do the bind mount and overlay on boot
Mlowerdir will be /usr/share/homebrew upperdir will be /var/lib/homebrew
Jif you PR let's do it in a testing branch or something, I'd love to bang on this for a bit
EAlso happy to test drive this
Mwe have some stuff in the testing branch right now for the bootc stuff
Mbut yeah we can add it there
Mi think we need to do symlink for build time since we don't use the privileged flag when building the container and can't do bind mounts inside the container
Jyeah, IMO let's toss all the new stuff in testing
Jand then pull judiciously into main, heh
Mokay I think I have a working idea.
Mdoing a local build
MLocal build worked but action build failed due to the directory already existing. Can workaround but off difference
MExtremely bizarre failures
Jprobably should have done it in a seperate PR?
Jbut whatever, next time, heh
MI said we were already using testing....
MBut I might be reverting all of this.
The installer is complaining that /home exists
The installer is complaining that /home exists
Jyeah
JI wonder if we can -f? checking manpage
MThe script didn't fail like this on my local build....
MCurrently concerned about docker vs podman right now and ancient podman on our builder
Jthe builders won't move to 24.04 until this summer
JJJbeta mid-may
MOkay. It doesn't think it's in CI for some reason.
MSo I'm going to have to switch to building with podman locally. Docker vs podman logic likely biting us
Joh man, just realized
Jwith it preinstalled we could put brewfiles with sets of packages in /usr/share/ublue-os
