Idea time @M2 @bsherman @1/4 Life : A
Idea time @M2 @bsherman @Kyle Gospo : A package-cache just like the kernel-cache.
JSo 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.
JAnd 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.
JBut then group then logically, so like, common, GNOME, KDE, etc so downstreams can granularly snag the sets of packages
JIt'd probably be inefficient to do one container per package, and one huge monolith probably is overkill.
MMy 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.
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.
Jyeah, 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.
Jactually man the combined changelog would be useful af.
BSounds like we want a yum repo which keeps old versions of packages around. 
BGitHub
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...
Jyeah basically this would do that but we wouldn't need to setup a yum repo
