Date:        Sat, 18 Jan 2003 09:16:11 -0700
    From:        Jim Bernard <jbernard@mines.edu>
    Message-ID:  <20030118161611.GA13495@zoo.bernard.org>

  | So, what's wrong with setting XAPPLSRESDIR in /etc/login.conf?

It doesn't work for "ssh remotehost /usr/pkg/bin/x-app" (and similar
invocations).   It doesn't work for stuff run from cron (OK, cron
rarely runs X applications, but the general principle of relying upon
env vars is what concerns me).

It also fails for anything run as a child of "env -i" (which is a very
good idea in general to sanitise the world - I do all my builds that
way for example).

Relying upon env vars in order to function is just plain wrong.
(It would be different if we were VMS, and had such things that were
outside the user context, that could be set by the system (or manager)
and would be used if not overridden -- but we're not.)


roskens@elfin.net said:
  | Since NetBSD could have the app-defaults under both /usr/pkg and /usr/X11R6,
  | maybe it would be better to modify the NetBSD config file for X11 to
  | include /usr/pkg/lib/X11/app-defaults/ in the XFILESEARCHPATH?

If we could do something like that, it would be nice,

but as fredb@immanent.net said:
  | Hard-coded paths in X to "/usr/pkg"? That sounds horrible

Yes, definitely don't do it like that.

In the past, when I used to manage all of this kind of stuff myself
(ie: before pkgsrc...) I had a "/links" directory ("/symlinks" would
have perhaps been a better name, but too long).

Then things (binaries, symlinks in shared filesystems, config files, ...)
can have coded into them paths that are /links/my-magic-name/whatever-I-want

In this case, perhaps /links/pkg-app-defaults could go into the
default search list.   If the directory (or the symlink in it) is
missing, no-one cares.   xpkgwedge could then make that symlink to
${LOCALBASE}/lib/X11/app-defaults.

It is still a hard coded (local) path, but one with much less impact
that hard coding /usr/pkg would have.

[Aside: if someone is going to do some local X mods like this, perhaps
also do something about /usr/X11R6/lib/X11/xkb - or at the very least
the "compile" sub-dirctory of that.   Because ...]


fredb@immanent.net said:
  | Actually, the clean solution is to install all such packages to /usr/X11R6,
  | which is what we do. ;-) 

Which unfortunately fails whenever /usr (or /usr/X11R6 really) is read only.

It really is a very good idea to make the system install directories
read only (for me, that is /usr with /usr/X11R6 a part of that).

The three issues with doing that (the only three I have found in years of doing
it this way - though I guess there might be more I have yet to experience) are:

1) X packages - and xpkgwedge with the union mount to handle app-defaults
handles that one just fine.

2) /usr/X11R6/lib/X11/xk/compile which the xkb stuff just insists on
writing into (I use another mount to direct that stuff into /var where
it belongs, though I suspect that /tmp would be just as good...)

3) "Your package tools need to be updated to ... Please \"make install\"
    in ../../pkgtools/pkg_install."
This last one is a real pain - something needs to be worked out so that
a pkgsrc version of pkg_install goes in /usr/pkg (${LOCALBASE}) rather
than in /usr/bin - and then gets used in preference to the /usr/bin one
for pkgsrc tasks when it is installed.

kre