Re: Question about the policy
[ As indicated in my VAC notice, I'll have some time available this
week. ]
Hilmar Preusse <hille42@web.de> wrote:
> Hi Florent, hi all,
Hi,
> Anybody has a clue, why the file, which determines if the map file
> should be read or not during generating updmap.cfg, should got into
> /var instead of /usr/share?
Good question. The short answer is because it is (arguably, see below)
useless to share these files between several hosts.
For those who don't have a hardcopy of the FHS under their pillow, here
are some quotes about /usr and /var:
/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between
various FHS-compliant hosts and must not be written to. Any
information that is host-specific or varies with time is stored
elsewhere.
[...]
/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary
files.
Some portions of /var are not shareable between different systems. For
instance, /var/log, /var/lock, and /var/run. Other portions may be
shared, notably /var/mail, /var/cache/man, /var/cache/fonts, and
/var/spool/news.
/var is specified here in order to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to
during system operation (as opposed to installation and software
maintenance) must be in /var.
Now, is it really useless to share them? Why?
Suppose we have a network with "master" being a host where all the TeX
packages are installed and several other machines using this
installation with, e.g., NFS shares. /usr/share/texmf is obvisouly
shared by master so that the other machines can use it.
[ Footnotes are in the middle of the text, sorry. This is because I
didn't intend to expand on the second sharing scheme initially... ]
I suppose[1] that in such a setup (which is why the /usr hierarchy
exists at all, AFAIK), you really want to do the configuration only
once, on master; not on the various "slave" hosts. Therefore, there is
no point in running update-updmap on the slave hosts: you run it once
one master, as you do with updmap, and make sure that the "final map
files" in /var/lib/texmf/fonts/map/ are shared by master. Consequently,
the files you were talking about
(/var/lib/tex-common/fontmap-cfg/<package>.list) need only be on master;
there is no point in sharing them.
This leads me to the question: why are the system "final map files" and
the format files under /var? These are only modified when doing system
administration, and it seems to me that they should[2] be shared, and
therefore under /usr.
I think the answer is "because they are (indirectly) generated by our
scripts", instead of being installed as dpkg-registered files, like the
bulk of what is found under /usr. However, this defeats[3] the point of
/usr and doesn't follow the FHS, AFAIS.
[1] Well, maybe some people want every host to have their own TeX
configuration, and only expect /usr/share/texmf to be a sharable
texmf tree. In this case, the various hosts may have different
font packages installed, and therefore
/var/lib/tex-common/fontmap-cfg/*.list become
host-specific files and thus belong to /var.
In this case, you can tweak fmtutil.cnf on the various hosts, and
therefore the format files are host-specific and belong to /var,
as they are currently.
However... it wouldn't hurt even in this case to have them under
/usr. That would allow for the other scheme and the .fmt files
would be shadowed by their host-specific equivalents...
($VARTEXMF coming before $TEXMFMAIN, etc.)
[2] Under the everything-is-shared scheme I assumed (i.e., all TeX
stuff is shared, except stuff such as /var/cache/fonts that may
updated by non-root users).
[3] Unless you only expect that that /usr/share/texmf should be
shared.
Summary: there are at least two ways to share TeX stuff in the sense
considered by the FHS:
1. For big networks centrally administered, you probably want to have
a master host and your gazillion slave hosts having exactly the
same TeX configuration. In this case, most of the TeX stuff should
go to /usr/share instead of /var.
2. OTOH, one could imagine a network of several machines independently
administered, where the /usr/share/texmf shipped by Debian is only
expected to be a sharable texmf tree. In this case, several things
are not necessarily useful to share that were considered useful in
the first scheme (for instance, format files). These things could
go to /var instead of /usr/share.
Maybe we should choose among the two schemes and document that in the
TeX policy (and maybe that has already happened and I forgot it).
[ I know I have been a bit unfriendly when you Cced me repeatedly in
2004f for posts on -tetex-maint, and I apologize for this.
Today, I would say that if you would like *me* to comment on a
particular subject, most notably when you are starting a new thread,
it is safer to Cc me. When I am already actively participating in a
thread, it is probably useless but I'll try not to bite you even in
this case. :-) ]
--
Florent
Reply to: