Re: [RFC] Breaking britney2's backward compatibility

2011-08-27 Thread Adam D. Barratt
On Thu, 2011-08-25 at 20:49 +0200, Julien Cristau wrote: > On Thu, Aug 25, 2011 at 19:42:24 +0100, Adam D. Barratt wrote: > > > The key question is whether we think it's enough of an issue that we > > want to stay in compatible mode until we could implement something like > > the opt-in model. > >

Re: [RFC] Breaking britney2's backward compatibility

2011-08-25 Thread Adam D. Barratt
On Thu, 2011-08-25 at 22:09 +0200, Philipp Kern wrote: > On Thu, Aug 25, 2011 at 08:49:03PM +0200, Julien Cristau wrote: > > On Thu, Aug 25, 2011 at 19:42:24 +0100, Adam D. Barratt wrote: > > > The key question is whether we think it's enough of an issue that we > > > want to stay in compatible mod

Re: [RFC] Breaking britney2's backward compatibility

2011-08-25 Thread Philipp Kern
On Thu, Aug 25, 2011 at 08:49:03PM +0200, Julien Cristau wrote: > On Thu, Aug 25, 2011 at 19:42:24 +0100, Adam D. Barratt wrote: > > The key question is whether we think it's enough of an issue that we > > want to stay in compatible mode until we could implement something like > > the opt-in model.

Re: [RFC] Breaking britney2's backward compatibility

2011-08-25 Thread Julien Cristau
On Thu, Aug 25, 2011 at 19:42:24 +0100, Adam D. Barratt wrote: > The key question is whether we think it's enough of an issue that we > want to stay in compatible mode until we could implement something like > the opt-in model. > I'd say turn off compatible mode, and see if that ends up being an

Re: [RFC] Breaking britney2's backward compatibility

2011-08-25 Thread Adam D. Barratt
On Fri, 2011-08-12 at 10:42 +0200, Julien Cristau wrote: > On Thu, Aug 11, 2011 at 21:57:22 +0100, Adam D. Barratt wrote: > > Obsolete binary packages in a configurable list of archive sections [...] > are not automatically removed when the source package is > > updated; instead they are kept in te

Re: [RFC] Breaking britney2's backward compatibility

2011-08-12 Thread Julien Cristau
On Thu, Aug 11, 2011 at 21:57:22 +0100, Adam D. Barratt wrote: > "Smooth updates" > > > Obsolete binary packages in a configurable list of archive sections > (currently "libs" and "oldlibs", although the latter is somewhat > debatable) are not automatically removed when the sourc

Re: [RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Russ Allbery
"Adam D. Barratt" writes: > Indeed - that's largely why they're appearing in the list. :-) "Old" in > this case means "no longer produced by a source in testing". > The above is the result of a "non-compatible" run, in which opensaml2 > 2.4.3-1, xmltooling 1.4.2-1 and xml-security-c 1.6.1-1 mig

Re: [RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Adam D. Barratt
On Thu, 2011-08-11 at 15:10 -0700, Russ Allbery wrote: > "Adam D. Barratt" writes: > > List of old libraries in testing (53): > > libsaml6: i386 amd64 armel ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel > > powerpc s390 sparc > > libxmltooling4: i386 amd64 armel ia64 kfreebsd-amd64 kfreebsd-i

Re: [RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Russ Allbery
"Adam D. Barratt" writes: > Not at the moment, but I suspect it wouldn't be hugely difficult to add. > This is an example of the output, from a recent(ish) data set: > List of old libraries in testing (53): > libsaml6: i386 amd64 armel ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel > powerpc s

Re: [RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Adam D. Barratt
On Thu, 2011-08-11 at 23:27 +0200, Philipp Kern wrote: > On Thu, Aug 11, 2011 at 09:57:22PM +0100, Adam D. Barratt wrote: > > Obsolete binary packages in a configurable list of archive sections > > (currently "libs" and "oldlibs", although the latter is somewhat > > debatable) are not automatically

Re: [RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Philipp Kern
On Thu, Aug 11, 2011 at 09:57:22PM +0100, Adam D. Barratt wrote: > Obsolete binary packages in a configurable list of archive sections > (currently "libs" and "oldlibs", although the latter is somewhat > debatable) are not automatically removed when the source package is > updated; instead they are

[RFC] Breaking britney2's backward compatibility

2011-08-11 Thread Adam D. Barratt
Hi, For those who missed either occurrence, we've been using britney2 as the primary implementation for testing migration for about six weeks now, and stopped running britney1 from cron a couple of weeks ago. imho, it's about time we stopped worrying about maintaining b2's backward compatibility