At 8:28 PM -0400 2002/10/15, Greg A. Woods wrote:

>  If you're about to install some non-pkgsrc software that happens to need
>  to use some other software that you've already installed via pkgsrc then
>  _you_ must simply tell that new software where the other software it
>  needs is located.  You should do the same to tell it about any software
>  you've already installed in /usr/local or /opt or wherever you choose to
>  install other software.

	Basically, you're saying that anything installed on a standard 
NetBSD system but which does *not* come out of /usr/pkgsrc itself 
should need to be fed a NetBSD-specific set of configuration details.

	That's a disincentive to use anything not covered by the 
package/port system (or, conversely a disincentive to use NetBSD), 
because not all other tools may be able to easily accommodate changes 
of this sort.

>                           Normally this should be a very easy process for
>  software that expects to make use of some other third party packages
>  (i.e. other software that's not normally expected to be included in a
>  basic unix-like OS).

	What about POSIX threads?  Myself, I would consider that to be a 
basic part of the OS, and should not have to be provided through a 
package/port.

>  You should also send bug reports to any package maintainers who ship
>  software which makes any unfounded assumptions about where any other
>  non-base system software has been installed, especially if those
>  assumptions cannot be overridden _and_ disabled as appropriate.

	This was not for a package.  Indeed, the package for bonnie++ is 
woefully out of date (back at 1.01), and the NetBSD patches for 
bonnie++ 1.01 had not been incorporated into later versions of the 
source -- either because the patches had not been submitted by the 
package/port maintainer, or because the maintainer did not notify the 
author in a manner that the author recognized as being a patch 
submission (and therefore probably discarded the message as likely to 
be spam).

	The upcoming version of bonnie++ (1.02d) should have the parts 
fixed which broke for NetBSD, but there is still the issue of the 
NetBSD-specific configuration details which need to be provided 
during the building of the source.

>  For example the one potential exception to this rule of thumb is
>  software using GNU Autoconf.

	Right.  And I'm pretty sure Russell uses autoconf.

>  (Remember though that GNU Autoconf and other things like it of course
>  make the job of pkgsrc much harder since they try very hard to explore
>  the target system for usable features and add-ons while pkgsrc must
>  control the build environment very very strictly.)

	The argument could be put the other way -- pkgsrc maintainers 
make their own lives (and the lives of anyone else that uses software 
which makes use of autoconf) unnecessarily difficult because they 
insist on putting things in a location that is unique to NetBSD.

	Who is the larger audience here?  Who is inconvenienced more?

>  If you wish to do that for your system then you should do so, but please
>  do not expect such things to be done for you, neither by the base system
>  authors, nor by third party software developers.

	Then /usr/pkg/bin should not be in the standard path, either.  If 
you're going to be non-standard, then you should be fully 
non-standard and people should have to deal with it.  If you're going 
to fix things up so that you are standard (or at least appear to be), 
then you should fix things up properly.  You most definitely should 
not stop halfway between.


	This bites things like devel/pth, too -- they simply take the 
contents of LOCALBASE and tack on bin/libtool, and expect that to 
work.

	Well, if libtool got installed in /usr/pkg/bin/libtool (due to a 
previous dependency), but LOCALBASE has now been changed to be 
/usr/local and devel/pth will be installing into /usr/local, it 
should not be dependant on $LOCALBASE/bin/libtool working -- it 
should instead use the path environment.

>  Software developers should never expect the system compiler to
>  automatically lead their build systems to find locally installed
>  software.

	For non-standard things, I can deal with that.  But on a NetBSD 
system, I would consider anything in /usr/pkg to be pretty standard, 
and therefore this discussion.

	Regardless, I certainly believe that POSIX threads are (or should 
be) standard out of the base OS -- no add-on package/port.

>  However if their own build system does this for them, as GNU Autoconf
>  _can_, then that's a potentially good thing for system administrators
>  (just, as I say, so long as those features can be turned off or
>  overridden when they might get in the way).

	Autoconf is only as smart as the person using it to help them 
build their system.  If they don't tell it to explicitly find 
pthread.h (because pthread.h is provided out-of-the-box on all the 
other platforms they have included as their development base and 
therefore they don't even think to ask themselves this question), 
then the compile will simply bomb when it comes down to trying to 
include pthread.h.

	The alternative is to try to teach the build system to 
automatically detect when critical headers or library files are not 
found, and to then go and install the appropriate package/port.  This 
way lies madness.

>  You might also try writing a little wrapper script for configuring
>  hand-built software.  For example when I hand-build a test version of
>  emacs I link it against libraries I've installed as packages in /usr/pkg
>  with this little wrapper on the emacs "configure" script:

	I wasn't hand-building bonnie++ 1.02c.  I was using the provided 
configure script, generated makefiles, etc....

>>   After
>>  all, the standard PATH definition for users includes /usr/pkg/bin, so
>>  why not make the other modifications as well?
>
>  Is that really true?  I didn't think it was.  In any case that's a
>  different issue.

	Yup.  At least in 1.6, it's in /etc/skel/.cshrc and /etc/skel/.profile.

>  Why not try your hand at creating pkgsrc modules for those things?  If
>  you manage to succeed then you could submit them back with send-pr and
>  share them with the rest of us!  ;-)

	I wish I had the time.  I have a talk for LISA 2002 that I am 
trying to prepare for, and then another one the next week for BSDCon 
Europe.

	Maybe once the conferences are over.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)