Re: Question about the policy
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?
>> 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.
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.
> 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; in scheme 2, the symlinks in slave:/usr/share/texmf
would point to files in slave:/etc/texmf, i.e., the slave-specific
configuration would be used. This is OK, except in case the slave is
not a Debian box. In that case, I don't know how the symlink would be
followed (imagine the slave is a Windows box...), *but* that hopefully
won't happen since I suggested to put the NFS-shared tree *last* in
$TEXMF. ]
> $ 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)
[...]
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
2. they all run Debian and have the same versions of the library
packages (which is basic admin stuff for such a network).
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.
> 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...
[ 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.
> I think that now I understand the two Schemes, but I'm still unsure what
> a decision about one or the other would mean.
Let's clarify everything first, then we can decide. I'm not even sure
both schemes are mutually-exclusive: probably scheme 2 wouldn't suffer
if there were a bit more than what is strictly necessary in the share
(e.g., .fmt files), since it should be included last in $TEXMF. So,
maybe we can accomodate both schemes easily.
> Except for the /etc/texmf issue, Scheme 2 can be done with the
> packages as they are.
Yes. And I am not sure /etc/texmf is even an issue.
> 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.
> 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?
> 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.
I remember at least some of it happened on -tetex-maint.
> As far as I recall, the main arguments against setting
> TEXMFSYSCONFIG=/etc/texmf is that there are some files in it that should
[...]
> The worst part about the switch is probably the transition.
But perhaps we don't need it. Waiting for your explanations. :)
--
Florent
Reply to: