Re: How to deal with teTeX's and texlive's RC licensing bugs
Hi Frank!
Great work you have done, thanks a lot!
On Don, 28 Sep 2006, Frank Küster 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.
Or I blacklist only those files which are in the Debian package and
recommend it? What do you think?
> >> 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.
For ethiop I leave if for now, too much work to sort this out ...
> >> 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.
Both too much work ATM for me, sorry.
> >> 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.
already done. blacklist bin-lacheck and recommend it from
texlive-extra-utils.
> >> latex-svninfo
> > not checked
>
> See the bug I just filed with X-Debbugs-Cc set to this list. Probably
> can be blacklisted.
I wrote already a bug report to support texlive. If we get an upload
compatible with texlive I will blacklist it and recommend/depend on it.
> >> latex-xcolor
> > old version in Debian
same as above, I wrote to Ohura-san to also fix pgf and latex-beamer.
This way I could blacklist all 3.
> >> 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.
Done.
> >> 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
See above.
> >> 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.
Kohda-san, please, do you have any knowledge about this? I guess we can
live with this conflict (texlive-lang-polish <-> ptex). If there is
someone who writes with ptex AND in polish, that would be funny.
> > 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.
I am in general against this axe, as I had bad experiences with it.
AFAIR there is the problem that there are no versioned
replaces etc, but this is long lost from my too small brain. ANyway. I
hope it is not necessary...
> 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.
depends I think is going quite well. Build depends is a desaster.
So what is missing is ethiop and ivritex, but man, I need a break now
.... ;-))))
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Università di Siena
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
ULLAPOOL (n.)
The spittle which builds up on the floor of the Royal Opera House.
--- Douglas Adams, The Meaning of Liff
Reply to: