Re: How to deal with teTeX's and texlive's RC licensing bugs
[dropping -release]
Norbert Preining <preining@logic.at> wrote:
>
>> dviutils
> the texlive tpm bin-seetexk provides more binaries, namely
> in addition dvibook and dvitodvi, and I didn't want to loose
> them
It seems these have been added to bin-seetex.tpm by Karl, so we can't
just tell dviutils' maintainer to package a new version. I think we
should declare Provides:/Conflics:/Replaces: (P/C/R) dvitutils in
texlive-extra-utils, so everything is fine for texlive users.
>> ethiop
> not checked
I compared the file lists:
$ findpkg -b ethiop > ethiop.list # this gives a list of all files in
# sid containing ethiop somewhere
$ grep texlive ethiop.list | \
sed -e 's@[^[:space:]]*/\([^[:space:]]*\).*@\1@' | sort -u > ethiop.list.texlive
$ grep "[[:space:]]tex/ethiop" ethiop.list | \
sed -e 's@[^[:space:]]*/\([^[:space:]]*\).*@\1@' | sort -u > ethiop.list.ethiop
$ diff -u ethiop.list.ethiop ethiop.list.texlive
This shows that the main difference is that texlive contains type1 files
for the fonts, which is a very important difference. I think we should,
in the long run, ask the ethiop maintainer whether he wants to maintain
an ethiop-fonts package, too. But as a short term solution I suggest
P/C/R.
>> ivritex
> not checked
Among the filenames in ivritex, some are also in other packages (like
arabtex. There are duplications both with tetex-base and
texlive-latex-base:
usr/share/texmf-tetex/tex/generic/babel/8859-8.def tex/tetex-base
usr/share/texmf-texlive/tex/generic/babel/8859-8.def tex/texlive-latex-base
usr/share/texmf-tetex/tex/generic/babel/cp1255.def tex/tetex-base
usr/share/texmf-texlive/tex/generic/babel/cp1255.def tex/texlive-latex-base
usr/share/texmf-tetex/tex/generic/babel/cp862.def tex/tetex-base
usr/share/texmf-texlive/tex/generic/babel/cp862.def tex/texlive-latex-base
[...]
usr/share/texmf-tetex/tex/generic/babel/hebrew_p.sty tex/tetex-base
usr/share/texmf-texlive/tex/generic/babel/hebrew_p.sty tex/texlive-latex-base
and so on. None of these are actual file conflicts, and since there's
no conflict with tetex-base, either, it means they are all in a
different place in the TEXMF tree (generic/ivritex instead of
generic/babel). So the only purpose that the Conflicts might have is to
prevent ivritex's files shadowing texlive's. But I don't think this
actually warrants a Conflicts; I'd rather document it in README.Debian
and arrange with ivritex's maintainer about who's going to provide what.
Or, as texlive people, contact ivritex upstream and ask them to upload
there releases to CTAN, so that they can be included in texlive.
>> lacheck
> not checked
Same version (1.26) in texlive and the lacheck package, no new upstream
versions since ages, besides the mandatory files the lacheck package has
one help file that texlive misses, and a /usr/share/bug script. Seems
like it could just be blacklisted.
>> latex-svninfo
> not checked
See the bug I just filed with X-Debbugs-Cc set to this list. Probably
can be blacklisted.
>> latex-xcolor
> old version in Debian
by Ohura Makoto, who generally seems to actively maintain his packages,
but with a long backlog and not much time. We could ask him whether
texlive should take that over post-etch (dropping xcolor support for
tetex users, unless we create a separate package), but for etch I
suggest P/C/R.
>> lhs2tex
> not checked
lhs2tex installs polytable.sty and lazylist.sty which are also in
texlive, but there are many more files in the lhs2tex package. Since
both files are quite old, I guess it doesn't hurt to have them at two
places, and we can just drop that conflict.
>> pgf
> old version in Debian with important bugs (backward
> compatibility is broken), I have prepared a new package for
> 1.01 and send all to the maintainers, no response
IIRC, there was a response "I'm working on it". Should we bug him
again? I guess so.
>> ptex-bin
> binary of the same name, ptex
Is the ptex package actually maintained? I only remember getting
bugreports about it... Anyway, we should check whether we can't P/C/R
it.
> Furthermore, the problem is that all these packages depend only on
> tetex, so as long as the maintainers don't upload new packages I cannot
> change the dependency order.
Yes, that's a problem. Solved with an axe with P/C/R, or by much more
work.
IMO opinion we should make it a release goal for etch+1 that nothing
depends or build-depends on tetex exclusively, so that we can
systematically check for build problems with texlive, and eventually
drop tetex in etch+2.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: