On Sun, Mar 28, 2004 at 02:32:59AM -0500, Greg A. Woods wrote:
> [ 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.

Thank you for your thoughts, Greg (and with which I completely disagree).
I shall treat your remarks with the respect they deserve.

In passing, I'd like to invite you not to use such terms as "lazy", or
trying to ride on a wave of invective by claiming that some things in
pkgsrc are not done "Right" simply because they don't coincide with
your desires/wants/needs.

Alistair