Subject: Re: pkg/5356: package system documentation is not simple or thorough enough
To: None <packages@NetBSD.ORG>
From: Soren S. Jorvang <>
List: tech-userlevel
Date: 04/24/1998 21:32:32
On Fri, 24 Apr 1998, Erik E. Fair wrote:

> >Category:       pkg
> >Synopsis:       package system documentation is not simple or thorough enough

> >Description:
> 	I am finding the package system documentation somewhat
> 	lacking. I love the package system theory - programs already

When pkgsrc became available, I tried making a few packages. It quickly
became less than satisfying, however.

For me, that was not as much because of idiosyncrasies in the package
system itself, but much more the bother associated with accomodating to
all the obscure builing methods used by various freely available

My experience with making (non-trivial) packages has been that what
takes the time is the trial-and-error builds because of (often broken)
build procedures and things like imake (kill kill kill).

I do not like finding myself reduced to excessive shotgun debugging and
it is not because I have been up for too many hours straight.

This is worsened by the desire to have "clean" packages, ie. ones that
do things like installing both unformatted and formatted (and
(un)compressed) man pages, preferably according to MANINSTALL and with
accompanying correct PLIST! This is currently done by way of unpleasant

So. I have been thinking about creating packages the same way that some
of the GNU programs in tree are now built, ie. 'shadowing'.
This could perhaps be made to build PLISTs dynamically. 

To make a new package easily this way, just capture a transcript from
the native make run, observe the CPPFLAGS+= needed and make a few small
and simple makefiles. The only "magic" that would be needed is perhaps a
pre-built config.h for GNU autoconf-using programs, combined with a
pre-made AUTOCONF that splattered out usual (machine-dependent) -Ds. 

(I haven't tried any of this out, yet.)

I think creating packages that way would be much easier and much less
prone to error. I don't think compatability with FreeBSD packages is
very important, since correctly porting these is usually as much work as
making new ones from scratch.