Date:        Fri, 17 Jan 2003 10:52:49 -0600
    From:        Rob Windsor <windsor@warthog.com>
    Message-ID:  <200301171652.h0HGqp804399@warthog.com>

  | I wasn't referring to that, I was referring to file
  | placement upon "make install".

That wasn't clear - but yes, obviously, as the existence of xpkgwedge
shows, making pkgsrc put files in any arbitrary location is possible
(if not always easy).   It is just that that is useless if you can't
rationally convince the applications to use them.

  | "just like PATH, but for app-defaults" is a fairly simple statement, any
  | way you slice it.

The statement is simple, doesn't make the operation simple for the users.
PATH is explained everywhere (elementary books, etc), and it is easy to
work out what to set it to - XAPPLRESDIR ??

  | Ah yes, everyone types /path/to/my/binary, all the time.

That wasn't the point.   The point was that things work if they are
invoked that way.   Nothing should ever require the existence of
an env var to function (for at least basic functionality) (and that
vi requires TERM set is a bug, it should operate in at least ex mode
without it).

  | So you're telling us that "mount the foo filesystem union on top of the bar
  | filesystem with the `hidden' flag" is easier for users
  | than "set XAPPLSRESDIR to /usr/pkg/lib/X11/app-defaults"?

Of course it is, because the users don't do it, I do.   They do nothing
at all.   Stuff just works.

In any case, I use xpkgwedge all the time, I wouldn't object if it
became the default, I'm just trying to explain why it is entirely
reasonable for the pkgsrc maintainers to not do that.

Installing xpkgwedge is easy if you can cope with dealing with its
requirements afterwards.  If you can't, you don't want it anyway.
If you can, just do it, what's the problem?

kre