LOCALBASE vs. X11BASE (head to head deathmatch!)

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ok, I'm kidding about the deathmatch part. :)

I have put some thought, and testing into this question though, so I thought 
I would post my results. First the conclusion. IMO the ideal technical 
solution would be to add a new variable, something like X11_CODE_BASE for 
the X11R7 bits, but default LOCALBASE, X11BASE, and the new one all to 
/usr/local. However, given that the resources to provide any kind of 
reasonable testing and user support to those different variables (there are 
8 combinations at least that would require testing, multiplied by > 15,000 
ports) does not now, and is not likely to ever exist, my actual 
recommendation is to collapse everything into one prefix.

I came to this conclusion by actually testing the various options. I decided 
to delete all my ports, and install something big and hairy to see where we 
stand. I chose gnome for my guinea pig (which also had the side effect of 
allowing me to torture-test the new version of portmaster, but that's 
another e-mail). My first test was to set LOCALBASE and X11BASE (*BASE) 
both to the same, non-standard location. Fortunately for me, that failed on 
the very first port it tried to compile (python), so I settled for setting 
them both to /usr/local.

The good news is that with *BASE set to /usr/local, everything built just 
fine, so we are at least PREFIX-clean enough so that things build. 
Everything runs fine for the most part as well, although when things failed, 
it was in non-obvious and annoying ways. In particular, gdm took me a long 
time to fix because of its multiple config file locations, and weird 
assumptions about PATH, etc. (It also has a really annoying "feature" of 
source'ing ~/.profile, but that's also another story altogether.)

These tests, and the work I put into stuff to get everything to work, lead 
me to the conclusion that it doesn't actually matter if we put the new bits 
into /usr/X11R7, or /usr/local. The two problems look exactly the same from 
the standpoint of the rest of the ports. For example, the problems I ran 
into with gdm need to be fixed by patching the original files with something 
like %%LOCALBASE%%, then sed'ing that out to be whatever the variable is set 
to in the ports (or make.conf). Thus, it doesn't really matter which change 
we make, if we start with the assumption that we're not going to install 
xorg 7.x into /usr/X11R6 (which is my understanding) then the solution to 
making the rest of the ports work with the new location looks the same 
regardless of the destination. Stated more simply, my previous contention 
that the real problem needs to be defined as, "Our ports need to be 
PREFIX-clean, period" seems to have been proved out.

This leads to my "ideal" solution, which would be to have the stuff split 
into 3 locations, instead of the current 2. There is a nice architectural 
purity to that, and I could envision scenarios where it would be useful to 
have things divided this way. The problem is that we simply don't have the 
resources to handle the 2 locations we have now (never mind enforcing 
PREFIX-cleanliness in general), and therefore I feel that the most rational 
way of dealing with this is to collapse it all into the same location. This 
does several things for us. It makes the development problem easier, since 
we'll always know where to find the bits (no artificial distinction between 
x11 bits, and "other" bits). It makes the support problem easier, because if 
a user is trying to do something non-standard, at least they will only be 
able to do _one_ thing in a non-standard way, which will make it easier to 
debug. It will also make the testing problem easier, since testing all the 
ports for installation into a non-standard PREFIX can be done with one pass 
on pointyhat.

It's also probably worth noting that I don't see any valid reason for 
continuing to support two discrete locations for ports to install to 
(LOCALBASE and X11BASE). If we're going to bite the bullet, we should bite 
the whole bullet, get it over with, and move on. If I'm understanding the 
discussions around DESTDIR correctly (and there is no guarantee that I am), 
then I think the work that will go into making that successful can also be 
leveraged into helping make collapsing the *BASE stuff successful.

This has been long, so if you're still reading, thanks! :) I hope that it's 
useful, and that we can continue having a rational discussion about the pros 
and cons of the various alternatives.

Regards,

Doug

- -- 

     This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE1YsIyIakK9Wy8PsRArDPAKCMIfXUsQITNTLChNOvQclRGzbCCACfbdeD
czbec9WIGtVWxlI+eD0AzEE=
=L2u8
-----END PGP SIGNATURE-----