Re: Question about the policy
Florent Rougon <f.rougon@free.fr> wrote:
>
>> Scheme 1,
>> =========
> [...]
>
> 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?
>
[...]
> 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.
I think you are right, basically. Except that I don't know whether and
how teTeX-3.0 will work withoug vartexmf (but we can always create
something like /usr/share/texmf-var/).
> 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 files in it must be accessible, whether by the network filesystem
allowing relative symlinks out of the exported share, or otherwise. The
reason why it is not in texmf.cnf is simply that all files in it are
connected to TEXMFMAIN by symbolic links. We still can switch to use it
as TEXMFSYSCONFIG, there are pros and cons to that.
> 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.
$ ldd /usr/bin/pdfetex
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40023000)
libz.so.1 => /usr/lib/libz.so.1 (0x40048000)
libkpathsea.so.4 => /usr/lib/libkpathsea.so.4 (0x4005b000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4006e000)
libm.so.6 => /lib/tls/libm.so.6 (0x40128000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4014a000)
libc.so.6 => /lib/tls/libc.so.6 (0x40153000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/bin/xdvi.real
libt1.so.5 => /usr/lib/libt1.so.5 (0x40023000)
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x40077000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x400d3000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400e9000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4013a000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40143000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4015a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40168000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40230000)
libkpathsea.so.4 => /usr/lib/libkpathsea.so.4 (0x40240000)
libm.so.6 => /lib/tls/libm.so.6 (0x40253000)
libc.so.6 => /lib/tls/libc.so.6 (0x40275000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x403aa000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
So there is some more dependency work to do. But I do not think that we
as Debian maintainers of a single set of packages should bother too much
about this. Either it's up to the local administrator, or it's a
question for the central Policy.
> 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?
I don't think so.
>> 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. :)
>
[...]
> 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.
And the local admin on the slaves, who adds map entries for the fonts to
the slaves' updmap.cfg, patterns to language.dat, etc. But you are
right, this is the same as in Scheme 1: Sharing means work for the admin.
> Am I clear enough this time?
I think that now I understand the two Schemes, but I'm still unsure what
a decision about one or the other would mean. Except for the /etc/texmf
issue, Scheme 2 can be done with the packages as they are. Scheme 1 can
be done, too, with the same exception, only if you go through the hassle
of sharing specific parts of /var. It would be much easier when we put
TEXMFVAR or its contents in /usr/share.
Generally, sharing would be much easier if /etc/texmf was
TEXMFSYSCONFIG. I should really look up the old discussions I had about
this. The easy to find is (only in German, with arguments *pro*
TEXMFSYSCONFIG)
http://groups.google.com/group/de.comp.text.tex/browse_frm/thread/8d49ca5c656332ea/01df03426fc0faaa?lnk=st&q=texmfsysconfig+group:de.comp.text.tex&rnum=1&hl=en#01df03426fc0faaa
The main part of the discussion, in english and with Thomas Esser,
probably took place in private, and I didn't keep all the Mails.
As far as I recall, the main arguments against setting
TEXMFSYSCONFIG=/etc/texmf is that there are some files in it that should
not be found by kpathsea. However, most of them are probably in
directories that are not searched, anyway. A second argument was that
it would make things more complicated to add one more tree. But in the
light of the sharing discussion, and of the problems brought up by
Markus Kohm in the above link (mainly, keeping upstream and Debian ways
as closely together as possible), maybe we should rethink this.
The worst part about the switch is probably the transition.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: