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
wwwoffle.
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
cu
Adrian
[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: