Re: State of tcl/tk for woody ?
Anthony Towns <ajt@debian.org> wrote:
> On Wed, Feb 28, 2001 at 04:14:04PM +0100, Gregor Hoffleit wrote: I noticed
> > that the tcl8.3/tk8.3 packages still have not yet made their way from
> > unstable into testing. update_execuses seems to imply that it's a problem
> > with the tcl8.3 source at the moment ('tcl8.3 (alpha arm i386 m68k powerpc
> > sparc source) is buggy (1 > 0)', 'not considered').
> >
> > This 'buggy' seems to be triggered by Bug#87708 'sharedlibextension
> > incorrect, breaks pkg_mkIndex', which in fact is a grave bug in 8.3.2-6.
>
> woody's meant to be releasable at all times: if tcl8.3 were included in it,
> then woody would have a RC bug, and wouldn't be releasable; likewise, if
> python were included without tcl8.3, even though it depend on tcl8.3 (I
> presume?), then that'd make python uninstallable in woody, which also would
> be a RC bug, and woody wouldn't be releasable.
>
> So, someone needs to fix 87708, assuming it really is a grave bug (makes
> the package unusable in all circumstances)...
Well, my impression is that the current setup of the package pool has a
tendency to force the developers to *delay* fixes of non-RC bugs until the
current unstable revision has been moved from into testing.
Imagine a revision 2.0-6 of an optional package had been in unstable for
8/10 days without any RC bugs, and finally all the architectures had catched
up. Therefore, this revision of the package would be moved into testing in
only 2 days.
Now if the maintainer would have fixed a few more problems and would upload
a new revision 2.0-7 to unstable, 2.0-6 would be completely dropped, and
2.0-7 would start again at 0/10 days, waiting for the autobuilders to catch
up etc.
If he would simply wait another two days, 2.0-6 would get moved into
testing, and he could then go on and upload 2.0-7.
This is currently the case for the python2 package. I'll delay 2.0-7 until
2.0-6 gets moved into testing, finally.
This situation could be fixed if superceded revisions (such as 2.0-6) would
still be kept and considered for a move into testing. Certainly, the BTS
doesn't really support this, since it's not perfectly clear from the BTS if
a specific bug does apply to a previous revision as well.
Gregor
Reply to: