Steve Langasek wrote:
> I think a better approach would simply be to regard application
> uninstallable-in-sid bugs as non-RC for testing purposes. Since the
> testing scripts will already refuse to process new libs that render
> applications uninstallable, the only impact here will be that certain
> packages will be uninstallable on a new, completely pristine unstable
> system -- which, frankly, is not a significant concern of mine.
> (Putting both testing and unstable in sources.list works just fine,
> IME.) Tagging such bugs appropriately and ignoring them until after the
> application makes its way into testing would probably serve our release
> process better than worrying about uninstallability problems caused by
> versions of packages which are themselves not yet release candidates.
Maybe I'm getting this wrong, but wouldn't that just accelerate application's
push into testing (somewhat) at the price of slowing down library updates even
further? Application developers could just impede libraries progress by building
against testing ("oh, this is more important than the update to your package, so
I'll be building against you previous version instead..."). But then certainly
noone would ever do this, would they?
The advantage of the current situation is that bugs are assigned there where
changes are needed for a resolution, which seems a good thing to me.
Cheers
T.
Attachment:
pgpFANLgQ7_H6.pgp
Description: PGP signature