Norbert Preining <[EMAIL PROTECTED]> schrieb: > Dear DDs! > > [Please Cc me] > > I am one of the contributers to the TeXlive project and we are in the > process of packaging texlive as debian packages.
Have you read our draft "Debian teTeX policy"? It's at http://people.debian.org/~frank/Debian-TeX-Policy/. I would be grateful if you - would take this as a guideline and adhere to it - give us feedback and criticize what you think is not appropriate. > Herein some questions > have arisen, the most prominent ATM is: > Are there any facilities to put binaries of different architectures > into debian packages? No. First of all, do you plan to include these packages into Debian proper, or do you just want to provide *deb packages on your TeXLive CD? In the first case, the rationale for the "No" is easy to give: A Debian package, in the first place, is a source package. Depending on its contents, you can produce different *deb's from it, so-called-binary packages: Either they can be "Architecture: all", e.g. this is the case for tetex-base containing the TEXMFMAIN tree. Or they are architecture-specific: If you create such a deb on an i386 machine, you'll get a package for architecture i386 (or i386-linux, if you like), but without setting up a cross-compiler, you can't get a deb for powerpc-linux. Therefore we have machines for every architecture that Debian supports that create the appropriate architecture-dependent deb packages. If you want a Debian machine to provide binaries for multiple architectures on a networked drive, the way to go would probably to create architecture-specific subdirectories below /srv (i.e. /srv/i386, /srv/ia64, /srv/amd64 and so on), mount them on the respective machines and do an ordinary apt-get install on one of them per architecture. > Best would be (if this is allowed according to the policy) to put > everything under > /usr/share/texlive/ > where there are > .../bin/<arch>-<os>/ > .../texmf (trees, various) > .../man > and put symlinks from /usr/bin/xyz to > /usr/share/texlive/bin/<arch>-<os>/xyz. This approach does not conform to the Filesystem Hierarchy Standard for Linux (http://www.pathname.com/fhs/). It might work, but I currently don't understand how you want to organise your symlink farm in order to allow the networked clients to use simple commands like "latex", not "latex-i386". > This way sharing the texlive directory allows easy integration into > other clients, and texlive won't interfere with tetex (if someone is so > crazy to install both). I don't think that this is a good way to look at it. Either usage of texlive will get very inconvenient: Type latex-texlive instead of latex, or create shell aliases; teach this to your Emacs/AUCTeX system, your lyx or kyle or however these things are named, install fonts and packages manually that have previously been installed via the package management system, and so on. Or if you try to make it convenient, you *will* interfere with tetex. Therefore I'd suggest that these packages be proper Debian packages, and that the teTex maintainers and you agree on a common set of configuration options, basic behavior of binaries, etc, as outlined in the Draft policy. Then in the future, packages can depend on something like a virtual package "tex", which would be provided both by teTeX and TeXLive. This is probably a lot of work, and requires continuous maintanence. The only feasible alternative that I see, however, is not to care about Debian policy at all, install TeXLive in /usr/local as is already possible, and just provide some hints or simple scripts for the adaptations necessary. Then it's up to the user to cope with the problems she gets (like other packages expecting different behavior from the "latex" command), but that's just the same now when I install TeXLive in /usr/local. > If someone on this list is interested I can communicate more details, > and in fact I would be grateful to hear comments and receive some > help in the design discussions. I suggest that you subscribe to the debian-tetex-maint list (If you filter mails with "Bug#<digits>" in their subject, traffic should be pretty low), and also have a look at the existing teTeX packages, especially how they manage updmap.cfg and fmtutil.cnf. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
