Re: Request for an "etch-ignore carte blanche" for alternative texlive dependencies
On Tue, Dec 12, 2006 at 08:38:42AM +0100, Frank Küster wrote:
> I would like to start a mass bug filing (not yet discussed on -devel,
> severity non-RC) on packages that depend on teTeX without an alternative
> TeXlive dependency. This is mainly targetted at lenny, but I would also
> like to encourage people to fix their bugs if they still plan uploads
> for etch.
> There's a little problem, though: Due to the larger number of texlive
> packages, it's not trivial to figure out the correct depends, and I
> think it would be a RC bug to switch from, e.g., correct
> Depends: tetex-bin, tetex-extra
> to a buggy
> Depends: tetex-bin | texlive-latex-base, tetex-extra | texlive-latex-recommended
> if it turns out that texlive-latex-extra or texlive-fonts-recommended is
> also needed.
Yes, it would be an RC bug.
> Would it be possible to get a "carte blanche" for an etch-ignore tag for
> any RC bug that
> - has been introduced by adding alternative dependencies on texlive
> - on a package that had correct dependencies before that
> - if the texlive alternatives are listed second, so that the working
> combination will be installed if no TeX system was installed before
No, I certainly don't think such bugs would warrant an etch-ignore tag,
especially seeing how they would be new bugs *introduced* after the start of
the freeze.
> Of course, the best thing to do would be to fix these bugs in an
> upload. However, if the bug is only detected shortly before the package
> is old enough to migrate, even that would hinder it very much, and
> therefore this situation makes it unlikely that people fix these kinds
> of bugs unless they're familiar with texlive themselves.
And, so? Why make these changes at all if they're not even *tested* to make
sure that the new depends are correct? That's not the kind of change that
qualifies for a freeze exception.
> On the other hand, I think that the overall quality of the distribution
> is better even with some bugs of that kind in it[1]
Adding an alternative that's *wrong* is not an improvement in quality over
having a lack of alternatives that nevertheless correctly specifies a
complete set of dependencies. If no one is taking responsibility for
ensuring the *correctness* of these changes, and it's my understanding from
your mail that no one is, then they don't warrant being let into testing
during the freeze.
If patches are going to be submitted following careful testing, that's
another question entirely.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: