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

Re: Request for an "etch-ignore carte blanche" for alternative texlive dependencies



Hi,

I've been asked in private mail why we want to do this mass bug filing
at all.  I paste here the relevant parts of my answer:

[why not wait until after etch]

We won't push that hard before etch is released, but it doesn't hurt to
fix those bugs now if a package gets an upload for etch, anyway.

[rumors that texlive does not provide identical functionality compared
to teTeX]

I've never heard someone claim that.  There are some packages missing in
texlive that were already obsolete when sarge's tetex was released, but
still included in current tetex, but besides that I don't think there's
any difference.

[ the bug reports we submitted so far do not specify exact dependencies
to use ]

Indeed, since this requires knowledge about the internals of the package
that needs more than a cursory look at the sources.  The splitting of
texlive is less buggy than tetex's ;-).  But I don't see how that can be
a reason not to file the bugs.  It might be a reason not to be able to
fix them promptly - and the problem of introducing RC bugs that way is
the reason why I sent this mail to -release.

[ why drop teTeX? I it dead upstream? ]

Yes, it is.  Thomas Esser (the te in teTeX) is still contributing to
TeXlive, but no longer putting together his own distribution.

[ why not let texlive Provide: tetex-*, and do "normal transition" ]

This would overload the buildd's and their ftp mirrors, because the
small "texlive" metapackage does not cover the complete teTeX, whereas
texlive-full pulls in really everything, about 2 Gigabyte of files.  And
it doesn't make sense to introduce new metapackages that map teTeX's
buggy splitting scheme on the texlive packages.

Regards, Frank

-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: