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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
