On Mon, Aug 04, 2003 at 08:33:31AM +0200, Thomas Viehmann wrote: > 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?
It would be amusing to watch them try; they would have to build by hand
on all 11 platforms, because the autobuilders will simply build against
unstable. I'm only talking about the case where the application has
/already/ been built, and is rendered uninstallable in sid because of an
soversion increment.
Yes, there are still some tradeoffs, and I expect it to be something
that gets discussed -- at least among the developers affected, if not on
debian-devel or debian-release -- before the maintainer makes an
executive decision on this point. I think a reasonable decision can be
reached in most cases without having to resort to discussions of a
package's "importance", either: in most cases, just looking at the
relative testing wait times for the packages in question, together with
an idea of the typical wait times for a library vs. a non-trivial
application, is likely to point to a solution. E.g.: libexif8 has the
same version in testing and sarge; kdegraphics has *no* version in
testing, even though the package has been in the archive for 11 months.
And honestly, my other idea would be to impose a moratorium on
dependency-changing library uploads three months before a release push;
since the above solution still doesn't address the issue of applications
rebuilding against libraries whose shlibs are not satisfied in testing.
(Samba, which I thought had a relatively simple dependency chain, has
been blocked for about 6 months now because of library dependencies
alone.)
> 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.
The disadvantage is that it prioritizes installability in sid over
currency in sarge. The reality is that uninstallability due to
dependency unavailability in sid is not *per se* an RC bug, because
unstable isn't what we *release*.
--
Steve Langasek
postmodern programmer
pgpfM55ftNiXA.pgp
Description: PGP signature
