Subject: Re: pkg/23017
To: NetBSD GNATS submissions and followups <email@example.com>
From: Alistair Crooks <firstname.lastname@example.org>
Date: 03/29/2004 18:50:36
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