Re: Question about the policy
Florent Rougon <f.rougon@free.fr> wrote:
> Frank Küster <frank@debian.org> wrote:
>
>> 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/).
>
> Why wouldn't it work with everything from /var, except /var/cache/fonts,
> moved to /usr/share/texmf?
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.
> Oh, yes. How could I forget that?!
>
> BTW: are really *all* files from /etc/texmf connected to TEXMFMAIN?
> In particular, is there no single program we ship that looks for
> its configuration directly in /etc/texmf?
>
> I think it is best like this, but would just like to be sure.
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.
>> We still can switch to use it as TEXMFSYSCONFIG, there are pros and
>> cons to that.
>
> What advantage could it bring in the context of this discussion? I
> suppose you are trying to avoid cross file-systems symlinks from /usr to
> /etc, but I don't think it is necessary. Symlinks work well across
> filesystems (as opposed to hard links), even in the context of NFS
> shares if I am to believe this message:
>
> http://groups.google.com/group/comp.os.linux.networking/msg/786458b9460e7b60
>
> We only need /etc/texmf to also be NFS-mounted, and the symlinks will be
> followed from /usr/share/texmf to /etc/texmf. The slave is thus using
> the centrally-managed configuration, everything's OK.
>
> [ This is scheme 1;
But this restricts scheme 1 to the variant where the slaves share
master's complete /usr/ hierarchy. On the other hand: You are right
that we gain nothing from introducing TEXMFSYSCONFIG in this context,
because we need the proper files in /etc/texmf, no matter whether the
(absolute) symlinks point to the slaves' /etc/texmf, or whether it
regards /etc/texmf as a separate tree.
> All these libraries could be installed normally as Debian packages on
> the slaves, AFAICS, even likpathsea4. The admin just has to make sure
> that:
>
> 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.
> 2. they all run Debian and have the same versions of the library
> packages (which is basic admin stuff for such a network).
Yes, you are right, and again: Nothing to care for in a Debian package,
admin work).
> I think we could even drop requirement #1 and make the whole setup very
> easy by providing a tetex-bin-shared package that only contains the
> binaries (with correct dependencies on the library packages, as computed
> by dh_shlibdeps), but does *not* depend on tetex-base and does *not* do
> anything in the maintainer scripts (no updmap, mktexlsr, etc.). You
> would just install this package on the slaves to get the binaries for
> the slave arch and it would automatically pull the libraries for the
> same arch.
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.
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
that this is a general shortcoming of Debian policy. Therefore it is
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. And I don't expect it to become a real issue for etch.
>> 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.
>
> Right, we're not required to write a HowTo and what not, but it would be
> better to ensure we are not changing stuff to support something
> (sharing) that is not practicable. So, let's just make sure that sharing
> is doable with our packages.
>
> OTOH, with today's hard-drive standards, I am not sure that sharing is
> still very useful (maybe to make the administration easier?...). And we
> don't have many requests regarding the issue to confirm that there *is*
> someone using such a setup...
Indeed. And to really make administration easier, we'd probably need a
centralized Debian-wide policy, again.
> [ Scheme 2 ]
>
>> 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.
>
> I am not sure I understand what you mean, so, let's elaborate a bit. In
> scheme 2, the configuration is slave-specific. You do whatever you want
> to your map files or language patterns and administer your slave host as
> you want (it may not even be running Debian!). Simply, the TeX guru of
> your network (who is running Debian, which is why we are talking about
> that here) shares his /usr/share/texmf tree with you to make your life
> easier. So, you can decide to incorporate this share in your
> installation by declaring it last in your $TEXMF.
>
> Locally-installed (i.e., slave-specific, not site-specific) )map files,
> lang patterns, etc., will be taken from local trees on the slave since
> they are listed earlier in $TEXMF. They are no problem to us.
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.
>> 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.
>
> Exactly. Except /var/cache/fonts, because /usr can be be mounted
> read-only and /var/cache/fonts can be updated by simple users compiling
> their documents (at least when this has been chosen in debconf...). The
> rest, AFAICS, is not _variable_ data. It is changed only by the admin
> when installing, upgrading, removing, regenerating formats, etc.
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. 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".
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.
>> 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)
>
> I don't see why it would make it really easier, based on my pararaph on
> symlinks above. Could you please elaborate?
No, I was mistaken here.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: