On Mon, 2010-05-03 at 14:54 -0400, Tom Lane wrote:
Jakub Jelinek <jakub(a)redhat.com> 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.
Fedora -- Freedom² is a feature!