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(a)hiwaay.net> wrote:
>>>
>>>> Once upon a time, Stanislav Ochotnicky<sochotnicky(a)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=t...
(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