Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, Dec 01, 2005 at 09:51:34AM +0100, Frank Küster wrote: >> Peter Samuelson <[EMAIL PROTECTED]> 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
