Re: testing process broken
Bill Wohler <wohler@newt.com> wrote:
> The process by which software gets into testing needs to be much
> more rigorous than it is. Consider:
>
> xlibs won't upgrade because of bugs in ssh-askpass, sndconfig
> and/or playmidi that are "fixed in unstable." Why then, did xlibs
> get moved to testing and not the others?
I don't quite understand this - upgrade bugs of this nature (not quite
knowing what nature you mean, admittedly, but I take it you mean
postinst bugs) are impossible to detect automatically in the general
case. The best mechanism we have is release-critical bugs being filed
against the appropriate packages, which (if done in time) will block
packages from getting into testing.
> reportbug won't install because it depends on python-newt which
> depends on a newer version of libnewt0 than is installed in
> testing. Why did python-newt get moved to testing and not
> libnewt0?
This sort of bug is *intended* to be fixed by testing, and usually is.
I'm not sure why it slipped through the net, but it's a genuine bug as
opposed to a design flaw (it seems you're presenting it as the latter).
Something appears to have gone weird with python-newt, as it happens:
python-newt | 0.50.17-1 | testing | arm, i386
python-newt | 0.50.8-2 | testing | alpha, m68k, powerpc, sparc
libnewt0 | 0.50.17-1 | unstable | alpha, arm, i386
libnewt0 | 0.50.8-2 | testing | alpha, arm, i386, m68k,
powerpc, sparc
Versions of packages normally have to stay in sync across architectures;
I'm guessing that this is due to some architectures having had
autobuilder problems recently and a bit of force having been applied.
It'll all be sorted out before release.
> wmakerconf-data and wmaker can't both exist together in testing
> because wmakerconf-data is version 0.62 and depends on wmaker 0.62
> but the version of wmaker is 0.61. Why did the new version of
> wmakerconf-data get moved to testing but not wmaker?
wmakerconf-data actually can be installed, because it only Recommends:
wmaker and Conflicts: wmaker (<< 0.62.0). Perhaps this is silly ...
> I would argue that the latter two of these problems should not exist
> in testing. The process by which software gets into testing (and
> eventually to stable) should ensure that the entire distribution is
> self-sufficient. No software shall be installed that depends on
> nonexistent software. This should not be a difficult problem as much
> of the software already exists in apt, dpkg, and probably others.
Modulo bugs, that's already implemented in the testing scripts (have you
looked at http://ftp-master.debian.org/testing/)?
> I *do* appreciate the Debian maintainers that bring us the best
> Linux distribution of all, and I *do* appreciate that testing isn't
> as stable as stable. However, our time is better spent finding
> legitimate bugs, rather than errors that could have been
> prevented/found by software.
The testing distribution is very new, and bugs are still being worked
out of the process. With 6000 or so packages and 6 released
architectures, it's also mind-bogglingly complicated at times, and the
dependency and conflict chains through Debian can get pretty horrific.
The design is solid, though, so give it a little time to get the rough
edges rubbed off before labelling it as "broken".
Cheers,
--
Colin Watson [cjw44@flatline.org.uk]
Reply to: