[tex-live] Re: binaries for different architectures in debian
frank at debian.org
Wed Jan 12 11:23:24 CET 2005
Norbert Preining <preining at logic.at> wrote:
> Hi Frank!
> Good to hear from a debian and TeX master!
Don't call me master - I've not been in the business for too long.
>> 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.
> Is this really an option? If I want to make a .deb which includes
> binaries, they should probably go to /usr/bin (or at least links from
> /usr/bin to /usr/lib/<package> I heard recently). If I put the binaries
> for each architecture into /srv/<arch> I cannot decently share them
> between different archs/machines.
As I wrote in my other mail to tex-live at tug.org, I don't see how a
"real" Debian package helps in this case. What you want is the contents
of a tex-live CD unpacked on some shared network drive (/srv for
example), and this can probably done right now. Clients can then mount
this somewhere and add the bin directories to their paths. If you need a
Debian package in this case, it's for the _Clients_ that do _not_ really
install tex-live, they need something to tell their package managment
system that TeX is available. Am I wrong?
> See my other email about the proposal
> of double packages, one including the actual binaries in a package which
> also names arch-os, and one including only the needed links for the
> current arch.
| In fact we would have packages for every architecture
| which is available for ALL architectures and install into
| and a package
| with debian-way of architecture, which depends on the right package for
| each arch (ie tl-dvips-bin for i386 depends on tl-dvips-bin-i386-linux
| eg) and just provides the right links.
I don't currently see why the tl-dvips-bin-<arch> packages that are
installable on all architectures would need to be Debian packages. You
can just as well use the existing tex-live directory structure and no
installation scripts, since the architecture-specific tl-dvips-bin
package will do the the symlinks and postinst stuff,
Furthermore, I don't understand how you want to arrange the
dependencies. Either tl-dvips-bin_$version_i386.deb depends on
tl-dvips-bin-i386_$version_all.deb - then you need to install
tl-dvips-bin-i386_$version_all.deb on every client, and you can as well
have only one package. Or it does not depend on it, but then again you
wouldn't need the overhead of Debian packaging for
tl-dvips-bin-i386_$version_all.deb, why not just copy the appropriate
parts from a tex-live CD?
>> > /usr/share/texlive/
>> This approach does not conform to the Filesystem Hierarchy Standard for
>> Linux (http://www.pathname.com/fhs/). It might work, but I currently
> Well, may be, but OTOH, `share' somehow means something.
According to the FHS, the complete /usr hierarchy is shareable, but this
is meant in the sense that they are independent of the state of a single
machines ("For example, the files in user home directories are shareable
whereas device lock files are not." from
/usr/share, the FHS says:
| /usr/share : Architecture-independent data
| The /usr/share hierarchy is for all read-only architecture independent
| data files. 
| This hierarchy is intended to be shareable among all architecture
| platforms of a given OS; thus, for example, a site with i386, Alpha,
| and PPC platforms might maintain a single /usr/share directory that is
| centrally-mounted. Note, however, that /usr/share is generally not
| intended to be shared by different OSes or by different releases of
| the same OS.
> I have to check
> th FHS, but if I want to share BINARY files, should they go to
> /usr/share or not?
No, they shouldn't. The FHS simply does not take this option into
account, except when you view the machine where the binary files are
installed as a mere fileserver (which might re-mount and itself use some
of the exported directories): Then it's /srv.
>> 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
> tl-<prog>-bin-<arch>-<os> packages installs <prog> into
> tl-<prog>-bin package depends on the tl-<prog>-bin-<arch>-<os> for the
> INSTALLING architecture, and just creates symlinks to the above.
This would work, but you've got the dependency problem outlined above.
>> I suggest that you subscribe to the debian-tetex-maint list (If you
> Will do it NOW.
I have also subscribed to tex-live at tug.org meanwhile, and I'd suggest
that discussion about the layout of tex-live packages takes place on
tex-live, and once we've found some feasible way to do it, the
discussion about common infrastructure for both teTeX and tex-live, and
about the TeX-Policy, can be done on debian-tetex-maint.
Inst. f. Biochemie der Univ. Zürich
More information about the tex-live