Adding packages to buildroot directly from updates-testing

[Ralf Corsepius]

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"?

If yes, then there would be no technical difference to what we have now.

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.

Ralf