On 31. 01. 19 10:56, Adam Williamson wrote:
> Just as a note, what's in the 'rawhide' repo right now differs quite a
> lot from what's in the buildroot as we haven't had a successful compose
> since 2019-01-21. This is for various reasons - most recently
> libreoffice needed rebuilding for the poppler soname bump and did not
> build successfully for nearly a week, and now lorax has a dependency
> issue.
Oh I was so happy that I managed to build libreoffice this night after it
timeouted on arm yesterday, and now it's lorax :(
I'm hypnotizing
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID
for days. When I blink I see "Fedora-Rawhide-20190121.n.1" written on a wall :D
Remind me why is this designed in a way that one single thing can block the
entire repo from even being created? I never really understood that part. I mean
of course we can't build images, but why not repos?
Because everything was designed when we had a much smaller set of packages and several things have come up over and over again.
1. Anything that breaks apart the distro from being 1 thing brings up the Extras vs Core boogeymen and massive flame wars that some packages have become 'core (can block a compose)' and others 'extras (can't block a compose)'. Nobody in release engineering/IT has any emotional energy to get involved in that anymore.
2. Some method could be done but it takes a lot of concentrated effort by the people keeping the current system working. We are not allowed to slow down releases and are being asked to speed them up. Slowing anything down causes people to complain mightily (even if they earlier complained things were broken).. so we have been going along as best we can.
3. There have been several quick 'oh that would fix everything!' fixes that people have tried and each one has fallen down to either a) the size of the repo b) sure that works but anyone can inject or alter a build with their own rootkit type problems (or similar security problems). That then takes time to figure out how not to do that.. and we fall into 1 & 2.
We can try to get out of this but people are going to have to deal with some breakage, slowing, etc.. or come up with an alternative solution and implement it.
> (it occurs to me to wonder whether it should be a matter of policy that
> soname rebuilds that involve libreoffice must be done in a side tag,
> but Rawhide package gating may render that concern obsolete soon).
Please, make that a policy! Soon can easily become months.
Do you want it to be a written policy or a coded policy? A written policy no one actually follows can happen shortly. A policy which actually looks to see if you are doing something and doesn't would be another thing.