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@xxxxxxxxxx> wrote: > >>> > >>>> Once upon a time, Stanislav Ochotnicky<sochotnicky@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
