Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de> writes:

> On 28 Jan 1999, Robert V. Baron wrote:
> > Actually, I'd like to argue that the pkg system infrastructure is part
> > of the base system and really should be there.
> 
> In a perfect world, yes. But given that pkgsrc and the pkg_* and
> bsd.pkg.mk it depends on evolve much faster than the base system gets
> updated, we had to move them over to pkgsrc to get in sync.
Ah, yes, I forgot how slowly we put out releases.  I get a new one
at least once a month.

"Alistair G. Crooks" <agc@westley.demon.co.uk> writes:

> Robert,
> 
> > Actually, I'd like to argue that the pkg system infrastructure is part
> > of the base system and really should be there.
> 
> They were part of the base system, and we moved them out of there. This is 
> because there are just too many problems trying to keep everything in sync 
> when they are not logically grouped together. As a counter example, take a look at 
> the FreeBSD ports collection, and see how many problems they run into whenever 
> they introduce some new feature. This is one of the best changes that we ever 
> made, IMO.

You bring up a very interesting point.  I wanted to build
coda5_client, but I did not want to put it into /usr/pkgsrc, yet.  On
freebsd, this just works.  You make a directory anywhere, put in the
port and it builds.  In our scheme, things are much harder.  This is
all because we use relative path names for the *.mk stuff.  So what
you need to do is create
	net/coda5_client
	mk as a link to /usr/pkgsrc/mk
This lets you build but all the packages dependencies fail.

What I'd like to suggest is that we/you go back to absolute path names
and root the tree at /usr/pkgsrc.  The base tgz would populate it.
And you would release periodic upgrades for mk,pkg_* independent of 
the base system and synchronized with the package system.  I think
that the package system itself then can be placed anywhere in the source
tree.  (Now using absolute pathnames to the mk and package stuff.)