Date: Fri, 12 Nov 1999 12:24:53 -0800 (PST) From: "Duane H. Hesser" <dhh@androcles.com> To: "Paul M . Lambert" <plambert@plambert.net>, Mike Meyer <mwm@phone.net> Cc: stable@FreeBSD.ORG Subject: Re: ldconfig finding libraries, but ld is not. Message-ID: <XFMail.991112122453.dhh@androcles.com> In-Reply-To: <19991111144938.B69565@pinky.plambert.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike and Paul
I agree with both of you (at least conceptually), regarding
installation locations of software (the topic here has wandered a
bit from the original Subject: line). I think your positions are
not so far apart, differing only in detail. It is certainly (in
my view) useful to keep optional software separate from the base
system.
Personally, I find it convenient (especially at upgrade time) to
keep separate
1) the 'base' system
2) the 'ports' system
3) locally ported/generated software
By default, the ports system combines 2) and 3), but is flexible
enough to allow them to be separated rather easily (for the most
part) simply by adjusting the variables LOCALBASE and X11BASE in
/etc/make.conf. I have read most of this thread, and have been
surprised that no one mentioned this. It is in the forefront of
my mind because I spent some time this summer in a 'major upgrade'
of my system, with a fresh install of FreeBSD 3.2 stable *and*
RedHat Linux 6.0 on a new 9 gig ultra-wide Atlas drive (for a while
there, I had a 'quad boot' system). The Linux system is just one
big mass (on one filesystem); there is no 'base' system, just a
kernel, an init, and everything else, all mixed together.
On the FreeBSD system, though, I spent some time re-designing
the filesystem layout (since it's possible to *have* a filesystem
layout) to support the above separation. On the 'old' FreeBSD
system, ports and locally installed software were intermixed
so that it was difficult to know which was which. The switch to
elf made it seem reasonable to re-install everything in any case.
Here is what I've done. It may not appeal to you, but the point
is that the ports system is flexible enough to let each of us
do our own thing. Those who see no advantage to separating
optional software ported 'elsewhere' and home-grown ports or
sources need do nothing. The rest of us only need to do a
couple of quick edits of make.conf and the ports supfile, and
maybe a couple of 'mkdirs'.
I've gone so far as to make separate filesystems for 'ports'
and 'local'.
/dev/da0s1d 3181934 1488777 1438603 51% /usr/local
/dev/da0s1f 2087950 959140 961774 50% /usr/ports
The result is the usual:
/usr/local/bin
/usr/local/lib
/usr/local/include
/usr/local/src
...etc..
where I put stuff I have personally mangled.
LOCALBASE is set to '/usr/ports' (the default is '/usr/local')
so there is also:
/usr/ports/bin
/usr/ports/lib
/usr/ports/include
/usr/ports/src/ports
...etc...
(the latter path really should be just '/usr/ports/src', but cvsup
is rather insistent about appending 'ports' to the supfile 'prefix',
so what the heck)
I have also installed the latest XFree86 distribution, which I
also wish to keep separate.
/dev/da1s2e 514202 329113 143953 70% /usr/X11R6
I set X11BASE to '/usr/ports/X11R6', so that X11 ports are also
kept separate from the 'stock' distribution (combined with all
other ports).
THE RESULTS of this have been encouraging, so far (I am not quite
finished yet, working at it in fits and starts, with a lot of the
old stuff still around; the framework is in place though, and the
next upgrade (circa 2039 :-) will be easier).
Most non-X11 ports honor LOCALBASE just fine; works like a charm.
A few still have 'local' hardwired in, but after many years of
hand-porting USENET distributions, etc. I'm not about to complain
about an occasional need to edit a PREFIX in a makefile. The ports
maintainers have more than once indicated a willingness to fix any
reported problems of this nature, but there have been surprisingly
few of these. I will go through my notes one day and send them what
I've managed to record; until then, no complaints from *here*.
The X11 situation is not quite as rosy; there have been quite a
few which needed hand patching. The problem seems to be a lot of
Imakefiles with BINDIR, INCROOT, MANPATH, and USRLIBDIR hard-coded
to use /usr/local. Even so, hand-patching these has not been much
of a burden.
I should note that I also provide a /usr/local/X11R6 dirctory,
although the only things there so far are some TrueType fonts.
On the *original* topic of this thread (having to do with
compiler/linker paths) it *would* be nice if configure scripts
(Imakefiles) took account of the possiblity that LOCALBASE (X11BASE)
might not be /usr/local, and were prepared to look both places,
and add the necessary '-I' and '-L' flags.
I would add my voice to any movement which might arise aimed at
changing the default LOCALBASE for ports away from '/usr/local',
although I do not find it strange in the least that the developers
of the ports system chose that prefix in the beginning. The
'/usr/local' convention arose rather strongly wayyyyyy back in the
mid eighties and has gained status in many minds as a (de facto)
'standard'. I would argue, though, that the extraordinarily useful
'ports' system is a slightly different animal than locally-generated
or locally-ported software beasties, that it is useful to keep the
two separate, and that 'ports' should therfore be ordained with
its own carefully selected pathname prefix. Given the current
(slightly imperfect) flexibility of the ports system, though, I am
not motivated to carry picket signs, organize rallys--anything like
that.
I just think it would be nice.
--------------
Duane H. Hesser
dhh@androcles.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.991112122453.dhh>