The following reply was made to PR pkg/28510; it has been noted by GNATS.

From: Robert Elz <kre@munnari.OZ.AU>
To: "Julio M. Merino Vidal" <jmmv84@gmail.com>
Cc: gnats-bugs@netbsd.org, jlam@netbsd.org, gnats-admin@netbsd.org,
	pkgsrc-bugs@netbsd.org
Subject: Re: pkg/28510 
Date: Tue, 29 Mar 2005 11:10:07 +0700

     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