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

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


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: