Le May 11, 2008 01:18:07 pm Andreas Barth, vous avez écrit : > * Luk Claes ([EMAIL PROTECTED]) [080511 19:09]: > > Adeodato Simó wrote: > > > * Steve Langasek [Sat, 10 May 2008 23:03:25 -0700]: > > >> That wouldn't be a good idea unless we first get support for keeping > > >> old library packages around in testing to allow asynchronous > > >> transitions. Otherwise, testing transitions would become far more > > >> brittle than they currently are. > > > > > > Oh, point. But I don't think there were plans to make the current > > > britney support build-depends, and britney2 *already* supports keeping > > > old library packages around. > > > > I don't understand why dependency checking plus build dependency > > checking would need support for keeping old library packages while > > dependency checking without build dependency checking doesn't need it? > > Eh, it's so: > > A transition are a couple of packages (up to a few hundered sometimes) > that are glued together and can only go to testing at the same point in > time. Issue with that is that all of them need to be ready at one > britney run. > > Now, there are proposals that reduce the glue possibilities (or: making > the glue clowds smaller), and there are some that increase the glue > possibilities. One can also use another word for that: Some make testing > migrations easier, some make them harder. If that's all what Steve meant, I'm not convinced that checking build-deps would make testing transitions "far more brittle". I *guess* it would make transitions at worst 20% harder.
> In Steves and my opinion, there are already enough (or even: too many) > large transitions which are already hard enough, so we want to avoid > changes making migrations harder unless there are (at least) the same > amount of easier things in place compared to now. > > > Making it easier: > - keeping old versions around > - autohinter > > Making it harder: > - build deps IMHO transitions are going fairly well currently. Symbols files support in dpkg-shlibdeps made it easier and will continue to make it easier. Also, in the "making it less harder", there could be a new hint to ignore build deps, say "ignore debhelper" if it's known that debhelper will have to be updated before releasing anyway. With such a hint (and maybe even without), I think that checking build-deps is a good idea even without any of the "making it easier". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
