Re: Question about the policy
Frank Küster <frank@debian.org> wrote:
> I can only speak for the last two(?) years that I closely followed this
> list, and I think it has not been explicitly decided.
OK. :)
> I think one important aspect for choosing is to check whether both
> schemes will actually work, and it seems to me that scheme 2 is very
> hard to do.
Probably I wasn't clear enough---scheme 2 is the simpler one (see
below).
> Scheme 1,
> =========
>
> after installing stuff on the master host, you need to do
> two or three things on the slaves:
[...]
This is more complex and error-prone than what I think we could do.
What do we have under /var, that is used by TeX stuff?
- /var/cache/fonts
It could be shared if the share gives read-write access (several
hosts updating it at the same time should be possible since as it is
now, it is already possible to have several users on a single host
running maketexpk at the same time).
Otherwise, it can be host-specific; the same pk files will be
created generated on the various slave hosts, but this doesn't
hurt much.
- /var/lib/texmf/fonts [ where lie what I call "final map files" ]
If, as I suppose in this scheme, master and slaves have exactly the
same TeX-related stuff accessible (installed on master, obtained by
the share(s) on slaves), they have the same TeX fonts installed.
Therefore, these files should be shared.
- /var/lib/texmf/web2c
Here, I see only format files (with the log files) and updmap.cfg.
Since master and slaves have the same TeX configuration in this
sheme, they have exactly the same pool size, etc. for every format,
therefore I think format files should be shared. The log files are
probably useless on the slaves but sharing them cannot cause any
harm, AFAICS.
updmap.cfg is useless on the slaves because only the final map files
are used by TeX-related programs, AFAIK. However, sharing it should
cause no harm either.
Simplicity would thus suggest to put all this under /usr/share.
- /var/lib/texmf/helpindex.html
Currently (I have tetex-base 3.0-3 installed), the paths in it are
broken. I don't know how it is generated, but since TeX
installations should be identical in this scheme, it should probably
be shared.
Basically, I am saying all that we have in /var currently could be moved
to /usr/share and be NFS-shared with the slaves. Unless I missed
something.
Now, you're asking, how do we do the whole setup work?
As I don't see /etc/texmf in the default texmf.cnf, probably this
directory does not strictly need to be shared (supposing all the
programs shipped in the tetex packages use kpathsea...). However, it is
IMHO much better to share it (for one, it allows users on the slaves to
check the configuration of their TeX installation easily).
The whole /usr/share/texmf tree on the slaves should come from the
master host. I think that mounting (via NFS or whatever) would work even
if the directory on the slaves is not empty, and the files locally
present on the slaves in that directory before the share is mounted
would be invisible.
Otherwise, make sure /usr/share/texmf is empty on the slaves. This
should not be difficult since I expect *none* of the real TeX packages
to be installed on the slaves (dummy packages generated with equivs or
whatever could be needed on them to satisfy dependencies upon the TeX
packages declared in non-shared Debian packages).
Another option, which wouldn't clash with Debian packages on the slaves
installing stuff under /usr/share/texmf, would be to mount the share
(i.e., master's /usr/share/texmf) on the slaves on
/usr/local/share/texmf.
Last thing: the executable files. Either you want all the slaves to be
indentical to master, even for non-TeX stuff. Then, you could share the
whole /usr hierarchy and be done with it. Or, you could have master's
/usr mounted somewhere on the slaves, say, /usr/local/master-usr and
create a bunch of symlinks (possibly in a .deb for easy distribution on
the slaves) such as:
/usr/local/bin/tex -> ../master-usr/bin/tex
Maybe this is bit tedious because you have to make sure the required
libraries are also accessible, but I don't think there are many of them
currently (only libkpathsea?), so this should be doable. Moreover, the
.deb with the symlinks could be shared... in real life, if everyone
agrees on the path /usr/local/master-usr or whatever it ends up being
("tex" should probably be inside...).
That done, simply configure your TeX installation on the master host, do
*not* run any maintainer script nor admin tool such as updmap on the
slaves, and you're done. Just make sure you have dummy packages on the
slaves so that if e.g. mozilla suddenly needs tetex (ha), you can
install it on the slaves.
Am I missing something?
> Scheme 2
> ========
>
> ist not completely clear to me. Do you think that the slave host can
> actually have differen _Debian_ packages installed? That seems to be
> impossible to me, or extremely difficult, maybe you can give dpkg a
> different root dir by some configuration option.
You're thinking about too complex things. :)
In this scheme, you are using your master host only as a means to easily
create and maintain (because of apt & dpkg) a texmf tree: the one
located in /usr/share/texmf on master. Your slaves can be whatever you
want (BSD, Solaris, maybe even Windows boxen). Simply declare on them
the texmf tree obtained by the sharing mechanism (in texmf.cnf, if using
tetex on the slaves) and make sure it doesn't have too high a priority.
For instance, if your slaves are Debian boxen, you could have your share
mounted on /usr/local/share/foobar and put in their texmf.cnf:
TEXMFFOOBAR = /usr/local/share/foobar
[...]
TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFFOOBAR}
(i.e, just append ",!!$TEXMFFOOBAR" to the default value of TEXMF)
kpathsea will do all the rest. But your slaves need not even run the
same operating system. They simply have access to a texmf tree that is
maintained by someone else on the master host (it could even contain
corporate style files). By declaring it to their TeX installation, the
job of keeping this tree up-to-date is effectively done by the admin of
master (whose job is effectively done by you, Thomas Esser, etc., since
Debian packages are a breeze to upgrade :)
Am I clear enough this time?
--
Florent
Reply to: