[ On Friday, October 3, 2003 at 10:59:18 (-0700), Jeremy C. Reed wrote: ]
> Subject: Re: I want X clients to install under X11BASE
>
> Some other operating systems include X-related software not
> maintained/provided by XFree86 under /usr/X11R6. For example, BSD/OS
> installs netpbm, fvwm, ImageMagick, kgames (not KDE, but uses Xaw3d),
> netscape, xcalendar, xsnow, xv, and xloadimage under /usr/X11R6.
> And Red Hat installs aumix-x11, ImageMagick, transfig, gvim, kterm,
> MagicPoint, mwm (Motif), rxvt, xjed, xplaymidi, xscreensaver under
> /usr/X11R6/bin.
> 
> It is normal for operating systems to install X-related software under
> /usr/X11R6/.
> 
> I know it is convenient and maybe cleaner to have pkgsrc install everyting
> under one hierarchy.
> 
> But it should be okay to separate.

I think you're mixing up several quite unrelated things here.  Let me
ramble on about some of the historical pressures which may have created
the current state of affairs for X11 and pkgsrc.

X11 was traditionally a third-party add-on package for all systems (and
to some extent it still is).

It has also been the case for a very long time now that some folks have
a near religious fanatacism about keeping add-on software and related
files separate from the files provided by their OS vendor in their base
system release.  I'll call this the "apartheid" approach to third-party
software.  It has very practical and very real reasons to exist in some
situations, but I use a term with very negative connotations to describe
it since those reasons are the result of a less than ideal situation
that has affected unix sysadmins for decades now.

(As a footnote let me say I once went so far as to force all add-on
software I installed on my SunOS-4 systems to not only install into a
hierarchy under /local, but also to never ever even write outside of
/local either, e.g. I made stuff write to /local/var, etc., though my
rationale for doing so at the time was that I did not at the time
control the SunOS-4 release process.  Now that I have control over my
own OS releases though I've reversed my approach and I install add-on
software directly into the base OS hierarchy on production systems --
i.e. I set LOCALBASE=/usr.  I still develop and test everything in
/usr/pkg though...  :-)

To some extent it was this desire by sysadmins to keep add-on software
separate which drove X11 maintainers to seggregate X11 software into a
separate hierarchy as well.

X11 is also a big and complex "package" containing many components and
this too has lead people to put it in its own hierarchy mirroring the
base OS hieararchy.

There are also some practical reasons (which are still relevant even
when one does not have to worry about clobbering base-OS files) to keep
at least the X11 commands in separate bin directories from non-X11
commands.  In theory these reasons also extend to other third-party
add-on X11 commands (and they apply regardless of one's religious
leanings on the "apartheid" approach to third party software).

So, X11 is still today given its own hierarchy under /usr by most OS
vendors, including NetBSD.  It really doesn't matter if some third party
maintains the X11 variant used by the OS vendor, or whether the OS
vendor typically includes components from several different maintainers
in their base X11 distribution.  It all installs under /usr/X11R6 or
whatever and the seggregation fans still treat it all as "base-OS" stuff
that they want to keep their add-on software well away from.

Now in the early days of pkgsrc there was initially a quandry with true
X11 related packages using imake since without jumping through a lot of
extra hoops the result was that they installed in /usr/X11R6 along with
the base X11 software regardless of where one pointed LOCALBASE.  This
situation was not very well liked by those who wanted to keep all add-on
software separate from anything supplied by the OS vendor.  Soon though
xpkgwedge was invented and it did all the hoop jumping on behalf of all
X11 imake-using add-on packages and with it everyone wanting add-on
software in a separate hierarchy was mostly happy.

Now of course ideally there would be a separate hierarchy for add-on X11
software, i.e. separate from other add-on software.  However as you've
discovered a great deal of add-on X11-related software no longer makes
use of imake (e.g. mozilla).  Some people think this is a good thing,
and some people don't.  Either way the result is that enough pkgsrc
users are using xpkgwedge and it seems likely to become the default for
pkgsrc (i.e. any imake-using add-on package will depend upon it) and
then at least all those who want to follow the apartheid approach to
third party software will be able to do so without even having to worry
about whether they've installed xpkgwedge or not.


> Very little needs to be changed to allow someone the choice to install
> X-related software to /usr/X11R6.
> 
> Can this be implemented?

In fact nothing needs to be changed to allow true X software
(i.e. software using imake) to install in /usr/X11R6 _iff_ one sets
LOCALBASE=/usr and one does _not_ install xpkgwedge.  :-)

(as you know some minor things need to be changed to make the use of
LOCALBASE=/usr work universally well, but that's a separate issue)

For the rest of the stuff, i.e. the X11 related software which does not
use imake, I'm with you -- I'd like to install it in /usr/X11R6 (or
/usr/pkg/X11R6 if I don't change LOCALBASE).  I haven't worried about
making this happen up to now though....

I do wonder why you have teTeX2-bin in /usr/X11R6/bin though -- there
may be one or two X11 related programs in teTeX, but primarily it is not
an X11 package as a whole.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>