On Mon, 2010-05-03 at 14:54 -0400, Tom Lane wrote: > Jakub Jelinek <jakub@xxxxxxxxxx> writes: > > gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override > > so that new libtool could be built. Likely you tried to built during > > that short window or NewRepo has been too slow after it has been untagged > > from dist-f13-override already. > > I see. It seems like this indicates a rather fundamental shortcoming in > the -override tagging mechanism. If random other builds that happen to > be submitted at the wrong time will see the overridden packages, what > happens to reproducibility? Can't we either fix it so that only the > specific desired builds see the override, or just prevent unrelated > builds from happening during the window? This is surely not going to > be the last undesired failure if things stay like this. > > regards, tom lane I welcome suggestions. Your first suggestion would require entirely new buildroot tags produced for each -override. New buildroots have a significant cost in spin up, upwards to an hour or more for the first repo generation. Do you really want to introduce an hour+ delay in your build every time you need an override, not to mention the vastly increased load on our backend filesystem? The second suggestion would put significant blocks in our build windows, since we get override requests on a daily basis. If only one could be done at a time, and we had to wait until the build was finished before moving on, we'd have a serious backlog and almost never have a window for doing builds without any override tags in play. We take a measured risk with our current system, because that's the best balance we can strike right now. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
