Re: Question about the policy -- /usr or /var -- how to implement NFS-sharing of parts or all of the teTeX installation
Frank Küster <frank@debian.org> wrote:
> Probably there are no problems. In TEXMF, TEXMFSYSVAR is right next to
> TEXMFMAIN, therefore combining them has no side effect. I wasn't sure
> about this, and if there had been "something in between", I would have
> feared problems.
OK.
> The Debian-specific stuff, namely update-*, of course look in /etc/texmf
> - but in directories that will probably not be searched by kpathsea.
> Everything else looks only in the TEXMF trees.
OK, thanks for clarifying.
> But this restricts scheme 1 to the variant where the slaves share
> master's complete /usr/ hierarchy.
How so? /usr/share/texmf can be shared and the binaries and libraries
obtained in a different way. For instance, libraries are installed on
the slaves normally via official Debian packages, and executables can
either be obtained:
(a) by symlinking from /usr/local/s?bin/<foo> to
/usr/local/masters's_bin_nfs_mounted/<foo> or
/usr/local/masters's_sbin_nfs_mounted/<foo>
[which requires slave and master to have the same architecture]
(b) or by using a tetex-bin-shared package as I indicated in my previous
mail
[which works no matter what architectures the slaves are made of]
>> 1. master and slaves are of the same architecture
>
> If only /usr/share/(texmf/) is shared, they need not be the same arch, I
> think.
This depends on how you get the binaries on the slaves (executables and
libraries): method (a) or (b).
> As long as there is no Debian-wide policy for actually sharing arch=all
> packages, I wouldn't want to introduce any tetex-specific things. Maybe
> it turns out that after a Debian-wide decision there are two kinds of
> maintainer scripts, one executed always, one only if the host is master.
Hmm, well.
> Frankly speaking, I get the impression that, although the FHS speaks
> about it, actually sharing /usr/share or parts of it in a Debian-based
> environment cannot be done without major work by the local admin, and
Ack. At least careful thought, if not work.
> that this is a general shortcoming of Debian policy. Therefore it is
I am not sure Debian policy is about to tackle the problem. You see, we
are discussing a lot of details specific to teTeX in order to devise
possible schemes, therefore I don't expect Debian policy to handle the
general problem in its entirety for every package. I admit it might give
some general hooks, as you mentioned with your "two kinds of maintainer
scripts", though.
> nothing we could solve only for teTeX; in fact any specific decision we
> make here could deprive the local admin from the possibility of doing it
> their way.
Instead of depriving, it could simply make it easier.
> And I don't expect it to become a real issue for etch.
ACK.
> Indeed. And to really make administration easier, we'd probably need a
> centralized Debian-wide policy, again.
As I a said, I don't expect that to happen; well, it could settle some
issues, but not all.
Anyway, I agree the problem of sharing doesn't seem to be what
preoccupies our users most. I went into all this so that we can explain
why .list files should be installed in /var/lib/tex-common/fontmap-cfg
as it happens currently or, if it appears more appropriate, somewhere
under /usr/share. Otherwise, I don't care much, personally. :)
> No, not to us. But the admin of the slaves has to update the local
> configuration when master's texmf changes, like adding updmap entries
> for new fonts, or removing them when the font is removed as non-free
> :-(. That is what I meant.
You're right here. The shared texmf tree can be used as is for many tex
files (.sty, .cls...), but not for font files, because the final map
files that could be moved there for the sake of sharing (and would thus
declare the fonts added by the admin on master) would be shadowed by
those in texmf trees that are local to the slaves.
> Fine. *But*: Without knowing the details, I am sure that there are
> really *good* reasons why upstream has decided to make a split between
> TEXMFMAIN and TEXMFVAR.
Well, I wasn't even sure this came from upstream.
> Note that they additionally have TEXMFDIST,
> which is the place where you unpack the tetex-texmf tarball, while
> TEXMFMAIN holds the pool files and stuff, and IIRC the starting
> configuration files which, if changed, are put into TEXMFSYSCONFIG.
>
> There are good reasons why we do not separate TEXMFMAIN and TEXMFDIST -
> because we have a package management system, and we need not be able to
> do "rm -rf $TEXMFDIST/*; cd $TEXMFDIST; tar -xzf
> /path/to/tetex-texmf.<new_upstream_version>.tar.gz".
OK, thanks for the reminder.
> But I am reluctant to just pool all of TEXMFMAIN, TEXMFDIST and TEXMFVAR
> into one directory. And I doubt that we gain much if we put TEXMFVAR
> besides TEXMFMAIN, as /usr/share/texmf-var. Pro: One share less to
> export and NFS-mount compared to the current situation. Contra: On a
> standard system without sharing stuff the admin must remount /usr/
> read-write just to be able to create a new format, or enable
> ukhyphen.tex which has been put into /usr/local/..., or add a new,
> locally installed font, etc.
In fact, I think there is no answer that will satisfy everyone. With,
for instance, format files in /var, you can rebuild your formats whether
/usr is RW or not. Good if you have /usr RO because it is mounted from a
RO device such as a DVD-R. But if your reason for having /usr most of
the time RO is security, you'll want all the files that are not variable
data to be in /usr instead of /var...
--
Florent
Reply to: