Adding packages to buildroot directly from updates-testing

[Matt McCutchen]

On Thu, 2010-12-16 at 18:11 +0100, Ralf Corsepius wrote:
> On 12/16/2010 06:00 PM, Matt McCutchen wrote:
> > On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote:
> >> On 12/16/2010 05:28 PM, Kevin Fenzi wrote:
> >>> On Thu, 16 Dec 2010 10:03:30 -0600
> >>> Chris Adams<cmadams at hiwaay.net>   wrote:
> >>>
> >>>> Once upon a time, Stanislav Ochotnicky<sochotnicky at redhat.com>   said:
> >>>>> Note that I am not saying things should go into buildroot as soon as
> >>>>> they are built, but as soon as they are in updates-testing. There
> >>>>> is a difference. There will still be reasons to use tags/overrides.
> >>>>
> >>>> That makes the push process much more fragile/difficult.  If you use a
> >>>> updates-testing build of package A, and package B (that depends on
> >>>> package A) gets rebuilt, then you may have a package B that can't be
> >>>> pushed to stable until package A gets pushed.  What if there's a
> >>>> security update on package B that needs to go to stable ASAP?
> >>>
> >>> Additionally, what if package A is built, after a few days serious
> >>> problems are found in it and it's deleted until the maintainer can sort
> >>> them out. What happens to packages B, C, D, and E that built against
> >>> this version? They will have broken deps.
> >> How would this scenario be different from what we have now?
> >
> > As it works now, if the problem is found before A goes to stable (and we
> > hope the testing process would find it), the build (or all of the builds
> > in the custom tag) can just be untagged.  The fallout is nicely
> > contained.
> 
> Hmm, are we talking about rawhide or release?
> As far as I understand, we are talking about "releases" ther 
> "updates-testing", where package "A" would land in "testing" in both cases.
> 
> The detail which is not clear to me: What does the current buildroot 
> contain? Does it comprise the packages in "updates-testing"?

dist-f14-build, which consists of updates + buildroot overrides + the
same inherited from previous distribution versions.  You can see the
details here:

http://koji.fedoraproject.org/koji/search?terms=dist-f14-build&type=tag&match=exact

(BTW, it seems that a custom tag would generally be better than a
buildroot override for the reasons we are discussing even if there's
only one dependent package, unless that would put some kind of strain on
the infrastructure.  Is a request for a custom tag more work than a
buildroot override request for the releng team?)

> If no, then we currently are at risk of building packages "depending on 
> A" against the "supposed to replaced" versions in "release/updates", 
> i.e. we are at risk of producing silently broken packages.

But this is no different from the case of a package C built against the
old A before the new A came into existence.

In most cases in which a new A makes it to stable, it will be
backward-compatible with packages built against the old A.  If it is
not, all dependent packages need to be rebuilt at some point.  But if B
happens to be rebuilt for some other reason while the new A is in
testing, performing that build against the old A is no different from
declining to rebuild C against the new A at that time.

-- 
Matt