Idea time @M2 @bsherman @1/4 Life : A
Idea time @M2 @bsherman @Kyle Gospo : A package-cache just like the kernel-cache.
6 Replies
So check it out, there's probably a bunch of stuff in copr that we can just shove in the packages repo, build RPMs via the actions, and then shove the results in an OCI container, and then have downstreams just copy and pull those.
And then we just renovatebot the spec files and then instead of having to ping someone to hit a copr button we can just manage it like everything else.
But then group then logically, so like, common, GNOME, KDE, etc so downstreams can granularly snag the sets of packages
It'd probably be inefficient to do one container per package, and one huge monolith probably is overkill.
My only mix is that we don't really need to carry a ton of versions of packages.
Kernel-cache started for fsync since copr dumps versions quickly and akmods to solve the fact that you can't run akmods easily.
That said, I do think for some things that we don't actively monitor and are in coprs could be better automated (Devpod).
The Nvidia breakages have made me think should we widen the cache net.
yeah, devpod is what got me thinking about this. like, it would also be nicer to have all the version updates in one repo for all of us to review as they come in.
actually man the combined changelog would be useful af.
Sounds like we want a yum repo which keeps old versions of packages around. 😎
And here’s another idea: https://github.com/ublue-os/main/issues/623
GitHub
Update build scripts re: alternatives workaround · Issue #623 · ubl...
When version 1.30 lands in Fedora ( https://github.com/fedora-sysv/chkconfig/releases/tag/1.30 ) we need to ensure all our workarounds for /var/lib/alternatives are removed and that all builds work...
yeah basically this would do that but we wouldn't need to setup a yum repo