Adding packages to buildroot directly from updates-testing

[Matt McCutchen]

On Fri, 2010-12-17 at 18:38 -0500, Orcan Ogetbil wrote:
> On Fri, Dec 17, 2010 at 1:36 PM, Matt McCutchen  wrote:
> > On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote:
> >> On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
> >> > 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?
> >> >
> >>
> >> Then you build the security update asap, and put it in testing.
> >
> > How does that solve the problem?  The point was that the new B may need
> > to go to stable before the new A is ready to go to stable, so there
> > needs to be a way (at least) to build it against the old A.
> >
> 
> Ah, you mean when there is a soname bump or such change in A? That
> happens less frequently, but as far as I know there is a koji command
> koji untag-pkg <tag> <package>
> which will help. It's not hard to write a script to
> -scan for a newer A than the specified version,
> -untag new A(s) if exists,
> -build B,
> -retag A(s).
> 
> Sorry, I missed your point in the first email.

That will work, assuming the user has permission to do the tagging; it
is essentially a buildroot override in reverse.  So the question is just
what we want to optimize for: more testing of packages while they are in
testing, or less fallout when a package in testing is broken.  Or if the
infrastructure problems are solved, we could use custom tags and get the
best of both worlds.

-- 
Matt