[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to find out why a package was removed from testing?

On Fri, Apr 01, 2005 at 06:56:45PM -0800, Steve Langasek wrote:
> On Fri, Apr 01, 2005 at 07:59:01PM +0200, Frank Küster wrote:
> > Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote:
> > > On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:
> > > Right, but open for 47 days already. If for this amount of days an RC
> > > bug is open and nobody seems to have cared enough to fix it or even
> > > provide a patch, I think it's justified hinting it out of sarge.
> > You are probably right.  However, removing a package should not be done
> > without
> > - adding a note about this to the release notes (Is there a package or
> >   pseudo-package for the release notes now? I don't think so).
> There is an upgrade-reports package, but not a release-notes package.
> Perhaps upgrade-reports is good enough for the moment, since removed
> packages are upgrade issues?
> Anyway, packages are removed from testing or unstable+testing all the time
> when they're not releasable, without necessarily looking at whether they
> were present in stable; and many of these may get back into testing before
> release; so it's not really practical to track removals until we get close
> to freeze (like, hmm, now).

This still catches only part of the problem.

I wouldn't assume that the majority of Debian users completely reads the 
release notes.

Consider someone discovers a remotely exploitable hole in wwwoffle
13 months after the release of sarge.

According to the Debian Popularity Contest, 1.5% of the Debian users run 

Consider one third of them completely read the release notes and removed 
wwwoffle. Then one percent of all computers running Debian 3.1 will be 
vulnerable - and there will be no DSA warning them.

You can argue "it was documented" - but the number of vulnerable
Debian 3.1 machines will still make the script kiddies very happy.

And wwwoffle is only one of many removed packages.

> The release team doesn't remove packages from testing for reasons that don't
> go through the BTS, and these are generally documented in
> http://ftp-master.debian.org/testing/hints/ as noted.

That's wrong.

The release team does remove packages for getting library transitions 
into testing. If a package affected by the transition depends on a third 
package that is not yet ready for testing, it might be hinted for 
removal by the release team without any mentioning in the BTS.

Consider e.g. the loop-aes-utils package would require libopenh323 [1].

You yourself would hint it for removal from testing today and it 
wouldn't have any chance of entering testing again for sarge [2] 
although it's completely bug-free.

Or a package might simply be removed because it depends directly or 
indirectly on a buggy package without being itself buggy.

> Steve Langasek


[1] that's only a fictive example, but I'm too lame digging through
    650kB update_excuses for finding some real examples
[2] due to it's versioned util-linux dependency


       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: