[ On Saturday, March 27, 2004 at 14:59:38 (-0800), Jeremy C. Reed wrote: ]
> Subject: Re: pkg/23017
>
> (Before I even started using LOCALBASE as /usr over 18 months ago, others
> posted that they have also used pkgsrc the same.)

Indeed I've been successfully using LOCALBASE=/usr for my production
NetBSD systems for even longer (at least two years).  My users very much
appreciate this level of software integration.

During that time I've found and fixed quite a few very questionable, or
at least very lazy, constructs in pgksrc.  Things like making wrong
assumptions about host software versions based solely on the non-unique
name of a file in a non-unique directory.  Sadly new such constructs
seem to appear on a regular basis.  For an OS project that claims to
pride itself on doing things "Right", this makes it look more like a
fallacy at times.

I think it's ludicrous that pkgsrc does not directly and fully support
the installation of packages directly into the same locations as any
base-OS software.  The artificial segregation of third-party software
into a (near) mirror hierarchy of the base-OS directories is almost
completely senseless in almost the majority of scenarios, especially
when all package contents and dependencies are carefully registered and
they can be installed without conflicts and can be easily de-installed.
Except for a few instances where unexpected filename conflicts occur
(though those are trivial to automatically identify even without having
a fully registered package set for the base OS provided you can build
and install the package twice, once with LOCALBASE=/usr/pkg, and then
again with LOCALBASE=/usr provided no conflicts are found in the first
test), the only time conflicts occur is when base-OS software is
explicitly being upgraded or replaced.

There are a few annoyances that I've had difficulty working around as a
third party developer, but they would be trivial to fix if the core
project supported LOCALBASE=/usr.  (e.g. the not-quite-matching pkg
hierarchy where "man" and "info" directories don't live in "share" where
they should)

Only a very tiny number of packages still clash with at least NetBSD
base-OS components, such as GNU readline vs. NetBSD readline.  Of course
these things wouldn't be as much of a problem if the NetBSD variants
actually implemented a fully compatible API and thus the third party
versions were not ever necessary for any packages.  However in all the
cases I've encountered like this so far it's been possible to simply
configure and build other packages which use these conflicting
"dependencies" in such a way that they don't require the conflicing
package(s) in the first place.  E.g. in the case of GNU readline I
simply don't install it at all and if some other package requires it
(i.e. won't work with the partial NetBSD native implementation) then I
modify the configuration to simply not use any readline library at all.
Except for myself my other users aren't normally sophisticated enough to
notice the difference.

-- 
						Greg A. Woods

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