>On Fri, 16 Apr 1999, Todd Vierling wrote:
>> For now, the pkg requires LD_LIBRARY_PATH to be set.

>Ugh. This is hardly `compatable.'

Yes.  It's a crock. And breaking user binaries from a previous release
(which is hwat happens if you remove ld.so from a pmax 1.3 elf system,
which has user-compiled binaries that refer to ld.so, not ld.elf_so)
isn't really on, is it?


>Why not just have PKGBASE=/usr for this package, by default? It's
>not as if this is `foreign' stuff rather than `NetBSD' stuff.

>As well, you have to keep in mind what's going to happen if I have
>other libs of that era kicking around in my /lib (say, from upgrading
>from 1.3 to 1.4). My ELF system will already have symlinks from
>/usr/lib/libc.so.3 -> /usr/lib/libc.so.3.1 (or whatever it's called);
>That symlink now has to point to /usr/lib/libc.so.3.2 if that
>happens to be the newer one in the package I just installed. If we
>can't do that, at least returning an error of some sort is better
>than having all programs silently still use the older library even
>after I've installed a new one.


Only the major version is signficant; the minor version is -not used-
at runtime.  So if everything is in /usr, then either all programs get
the `old' libc (which breaks programs which make new syscalls) or they
get the `new' libc (which breaks programs that relied on bugs in the
old libc, or rely on behaviour that's changed).

Installing _any_ libraries with $PKGBASE=/usr will break something--
unless we bump library major numbers across releases. Which we don't.

I dont see how that fits, at all, with using $PKGBASE=/usr here.