Date:        Mon, 28 Mar 2005 10:23:39 +0200
    From:        "Julio M. Merino Vidal" <jmmv84@gmail.com>
    Message-ID:  <1111998219.404.7.camel@dawn.home.network>

  | That won't always work.

Almost nothing always works.    That's not needed.   But something that
works for almost everyone would be nice.   And that includes all those
who believe the pkgsrc theory that LOCALBASE can be put (almost) anywhere
(which in general, it can).

  | Suppose a user installs (as many, many people does) NetBSD+X11 from
  | binary sets.  This means that, with your "fix", X11 will look inside
  | /usr/pkg/whatever for files.

I have absolutely no idea what you are getting at there.   It doesn't
make the slightest bit of difference what is installed from where, or
even in which order.

  | Now, that user installs pkgsrc and sets his LOCALBASE to /opt/pkg.
  | And there you go.  The "fix" doesn't work any more and he is forced
  | to modify the environment.

When pkgsrc is installed, the user installs the union mount (there's no
point doing it before that), and in your scenario, it would be
/opt/pkg/lib/X11/app-defaults that would be mounted (as a union above
whatever directory the standard X installation has been compiled to use).

Why not test my suggestion and see for yourself, try to find realistic cases
where it fails (and any other system wide setting of a single pkgsrc
app-defaults directory would work).

  | Not to mention that, if he has two LOCALBASEs, one in /usr/pkg and one
  | somewhere else, X11 will always find, if not told otherwise, the stuff
  | in /usr/pkg, thus probably causing confusion to the user.

Hmmm.... Two localbases and you're worried about app-defaults causing confusion?

It would be nice if stacked union mounts worked (last I heard they caused
crashes, so I just stay away), which would take care of this problem (to
some degree, if the same basic package (different versions) is installed
in multiple places, then the user is always going to have to select which
one is wanted - the solution in the PR does nothing at all, your env var
solution, allowing the X libs to be told where LOCALBASE is, either needs
to get real complicated, or also only handles one).

This is I think one of the things were we can just say "not supported"
and leave it to the user to set the standard X env vars to get the effects
that are desired (which might mean a different setting in a script just to
run one particular version of a program).

  | Another possible solution is to add a default value for the correct
  | environment variables in /etc/profile or something like that,

No, that's not a solution at all.    Env vars that are required for things
to work are a disaster.   There is too much that unsets the things (usually
for very good reason).   They're great to allow normal default behaviour to
be overridden, and useless to set basic system setup.   That's why we have
/etc/localtime and don't require TIMEZONE to be set (and many more).

  | so that the user can change them at will, if needed.

Yes, env vars to allow the user to change the defaults are fine.   But
X already has that - there are plenty of env vars (too many env vars) that
allow the user to say where to go looking for app-defaults files.

Nothing new is needed there.   In fact, use of them is what is currently
recommended for xpkgwedge use (though it only matters to a very small handful
of packages, almost nothing needs to locate an app-defaults file to work).

It is because the env var solution is not really an acceptable solution that
the PR was filed (I suspect) - seeking a way to simply have things correct
for the average user, and not require env var settings.

I have complete sympathy for the desire - just the mechanism proposed was
neither sufficient (as your response pointed out - LOCALBASE isn't fixed
at /usr/pkg) nor necessary.

  | After all, /etc/man.conf
  | already comes with a default path pointing to /usr/pkg...

That kind of solution would be fine too.   But note that this isn't
env vars (man, like X, and lots more, has env vars that allow the
path to be altered by the user, but things work just fine without
anything set in the usual case - and the system manager can just edit
man.conf if /usr/pkg isn't LOCALBASE on his system).

If you want to implement a solution like that for X app-defaults files,
go for it - but the way to be like this would be to add something new
in /etc/X11/XF86Config (and then work out how to get something similar
for those other X servers that don't have a config file).

That would be fine, no objections at all.

But we don't need /usr/pkg compiled in, and we don't need yet another
env var in addition to the set that X already has which are already up
to the task (as much as env vars ever can be).

kre