[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binaries for different architectures in debian packages



Hi Frank!

Good to hear from a debian and TeX master!

On Die, 11 Jan 2005, Frank Küster wrote:
> 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. 

Thanks, I will do it immediately.

> > 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

I understand this (I have packaged some debs already). You
missunderstood the problem. I am speaking about the option to SHARE
stuff via the network.

> 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. 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.

> > 	/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. I have to check
th FHS, but if I want to share BINARY files, should they go to
/usr/share or not?

> 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". 

tl-<prog>-bin-<arch>-<os> packages installs <prog> into
/usr/share/texlive/bin/<arch>-<os>/<prog>

tl-<prog>-bin package depends on the tl-<prog>-bin-<arch>-<os> for the
INSTALLING architecture, and just creates symlinks to the above.

This way all the files are  found easily, since any binary (in texlive)
checks the actual location of it, then searches for
../../texmf/web2c/texmf.cnf (and other pathes), which would go to
/usr/share/texlive/texmf/web2c/texmf.cnf which is exactely what I want.

> > 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,

No, see above.

> or create shell aliases; teach this to your Emacs/AUCTeX system, your
> lyx or kyle or however these things are named, install fonts and

same no.

> 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.

This is a completely different thing. I guess fo now we wont find a
common denominator. But since (AFAIK!) TeXLive's texmf is a superset of
tetex, this should not be a serious problem.

> 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 definitely a good idea! But first we have to get other things in
order for us to know wether our approach is feasible at all.

> I suggest that you subscribe to the debian-tetex-maint list (If you

Will do it NOW.

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
sip:preining@at43.tuwien.ac.at                             +43 (0) 59966-690018
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
AMLWCH (n.)
A British Rail sandwich which has been kept soft by being regularly
washed and resealed in clingfilm.
			--- Douglas Adams, The Meaning of Liff



Reply to: