On Mon, Apr 10, 2006 at 08:33:04PM -0700, Bernice Barnett wrote:
> Siep Kroonenberg wrote:
> >On Sun, Apr 09, 2006 at 12:12:34PM -0700, Bernice Barnett wrote:
> >>Siep Kroonenberg wrote:
> >>>On Sat, Apr 08, 2006 at 06:29:42PM -0700, Bernice Barnett wrote:
> >>I do have a local tree, that is what localtexmf is. It was integrated as
> >>part of the original setup. The point is that it can only be used by
> >>users who have administrative rights. I haven't ran across any
> >>documentation that discusses user vs. machine trees so am surprised that
> >>it is an issue. Updates for example, effect all users. The update also
> >>updates the file names (or whatever it's called) database. Is that
> >>database a per user thing? If not, having separate trees would make no
> >>sense. If so, why does update bother to refresh it? I think I'm confused
> >>and would appreciate a "statement of principles".
> >You can have more than two trees. The one which receives generated
> >files is called the local tree. You can specify this on the roots
> >tab of MikTeX Options. This designated local tree holds the
> >databases for all active trees.
> >On the MikTeX installation of our department, we have one main tree
> >with files from the MikTeX distribution, one tree with department
> >stuff, and each user has his own private tree with his own stuff in
> >his own private file area. This private tree also contains databases
> >for itself, the department tree and the main tree.
> As I've said above I DO have a local tree. The problem is only
> administrative users seem to have access to it. Note, all my "users" are
> just different accounts with different privileges. (I made this point in
> my original message.) I would guess that your university runs a domain
> and users are on different machines.
> -- Jeff Barnett
What you would need is to let per-user settings of trees overrule
global settings. I did some testing. Although I could define a new
own `local' tree as unprivileged user, and let MikTeX Options write
a filename database to that tree, it turned out that MikTeX wouldn't
remember this new local tree. So this wouldn't be very useful.
You could maybe fix it with registry hacking, but it appears that
the official interface doesn't support different local trees for
different users if MikTeX is installed as a shared program.
Unless, of course, I am overlooking something.
There are two reasons why we don't have this problem at our
department: 1. Even though everybody gets the same MikTeX settings,
their local tree x:\miktex is a different network directory for each
user, and 2. since settings are per-user, users can probably change
local and other trees at will. This configuration is done by a
custom installer, not by the regular MikTeX setup program.