Re: binaries for different architectures in debian packages
Norbert Preining <firstname.lastname@example.org> 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
- 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
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
> where there are
> .../texmf (trees, various)
> and put symlinks from /usr/bin/xyz to
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
> 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
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.
Inst. f. Biochemie der Univ. Zürich