Re: texlive-basic_2005-1_i386.changes REJECTED
Steve Langasek <vorlon@debian.org> wrote:
> On Thu, Dec 01, 2005 at 09:51:34AM +0100, Frank Küster wrote:
>> Peter Samuelson <peter@p12n.org> wrote:
>
>> > [Frank Küster]
>> >> > Why do we need two packages containing the "latex" command, for example?
>
>> >> Why do we need N packages that provide MTA functionality?
>
>> > That's not equivalent. An equivalent question would be more like "why
>> > do we need N packages all containing the source code for exim and
>> > building a binary called /usr/sbin/exim?" What I mean is, AFAICT, if
>> > you get past the packaging, tetex and texlive are the *same* source
>> > code and the *same* data - not just two different implementations of a
>> > similar interface.
>
>> The source of teTeX is a *subset* of TeXLive's source, modulo versions.
>
> Then we definitely shouldn't need two copies of it!
Please go ahead and prepare a package of teTeX-3.0 from a version of
TeXLive. Or don't do it - it's impossible, because there is no released
version of TeXlive that corresponds to teTeX-3.0; probably there is not
even a repository revision that corresponds to it; and maybe there is
not even a corresponding version for every single file. Remember that
both are a compilation of TeX-related programs, and if during testing of
teTeX-3.0 Thomas Esser found a patch necessary for program x, he has for
sure communicated it to x's upstream. But upstream might never have
released a version of x that only contains that patch, but then a
version of x with that patch plus further changes made it onto CTAN and
into TeXLive.
This is what I meant with "modulo version".
But even then it was an oversimplification by me to say that teTeX is
a*subset* of TeXLives's sources. In fact there are the system
maintenance scripts (like mktexlsr, fmtutil, updmap), which were
originally written by Thomas Esser, but have subtle differences in
TeXLive.
The "we don't need two copies" argument would only be valid if we had
separate maintainers of pdftex, latex, dvips, dvipdfm, ConTeXt, and all
TeX and LaTeX input files, including fonts. All of them could then take
their source from their upstream (either CTAN or a project homepage),
coordinate with each other, and upload it to Debian when they have made
sure everything works together.
But this would mean to replace teTeX or TeXLive by a new TeX
distribution, let's call it DebTeX. It's not feasible, and it doesn't
make sense, and therefore we either have one TeX system with one set of
sources, or two of them with two. I think we have shown enough good
reasons to add TeXLive as a second TeX system; I agree with Josselin
that we will have to reconsider whether we still need the smaller one,
teTeX, once TeXLive has established itself within Debian. But let's not
do this before we even tested TeXLive.
>> It will serve our users to be able to install, as a Debian package, the
>> parts of TeXLive that are not included in teTeX.
>
> Then why can't TeXLive build binary packages:
>
> - tetex-bin, containing all the usual goodies it provides today
Because the source isn't there. It's a different version. There are
differing design decisions between teTeX and TeXLive. This could be
handled by patches, but who's going to do this?
>> It would not do our users any good if we dropped teTeX right now and
>> switched everything to TeXLive (especially Debian developers would be
>> quite angry about the numerous FTBFS bugs, and "nonresponsive"
>> maintainers who are overworked).
>
> They would be justifiably angry if you broke existing tetex
> build-dependencies; but if TeXLive is indeed a superset of teTeX, there is
> no reason at all why a switch to TeXLive should *require* breaking existing
> packages.
Even updating teTeX to 3.0 revealed lots of bugs in Build-depending
packages. Simply switching to TeXLive (and falsely calling it tetex)
with its much less mature packaging would bring up more of them, plus
its own bugs.
Maybe I should put the argument differently: If we had a large TeX
Strike Force, with lots of interested, coding-eager members, some of
them partly payed for Debian work (as the X Strike Force has AFAIK), it
might be feasible to do this switch (although I doubt it would be
desirable). But we haven't; teTeX is currently maintained mainly by me
as the only active DD, with some advice by Atsuhito Kohda and Julian
Gilbey, and three non-DD's with SVN write access. One of them is also
maintainer of TeX-live, and we all are doing this in our free time,
nobody has a job connected with Debian work. I should be writing a
paper right now instead of writing this mail
>> I also think that teTeX is a long-term alternative (e.g. for people who
>> want a reasonably sized, reasonably recent TeX system without thinking
>> much about details, or for buildds).
>
> Sure sounds to me like this could be provided by careful division of the
> TeXLive contents between binary packages?
You are wellcome to join us, helping to make the careful decisions, and
implementing them. We are currently reworking the splitting of teTeX to
make it more useful for Build-Depending packages, but if you drop in and
show us how we can do with TeXLive instead, why not?
>> Becaues of the internal dependencies of a TeX system, it is not trivial
>> to take out the things from TeXLive that are already in teTeX, and only
>> package the rest.
>
> Does this also apply to the suggestion of having a core "tetex" package
> built from TeXLive sources, plus a shell "texlive" package depending on it?
>From what I know of TeXlive, yes, it does. But I didn't even have the
time, and won't have in the next months, to have a close look at
TeXLive's sources and how they are organized and built. Except if now
all you guys drop in and tell us: "Look, here's a prototype
implementation, we've built a third of tetex-bin's (and -extra's) direct
and indirect Build-dependencies with it, works fine - we just need your
experience for the details."
I do not dream.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: