On Sun, Jun 08, 2003 at 12:37:00AM +0200, Julien T. Letessier wrote:
> In fact, the eventual bootstrap-pkgsrc .tgz would already contain a package
> database. The current process registers the 'digest' package -- so my
> bootstrap tarballs come with this one package already registered.

This is exactly what I do.  Then you manage pkg_tools just like any other
package.  And it can be 100% packaged if desired--just install the base
pkgtools chrooted.  (Actually, I don't use bootstrap-pkgsrc at all, my
"bootstrap" .tgz is built from what's in pkgsrc.)

> This is probably the reason why 'pkg_install' doesn't register a package --
> because it's essential to the package manager. Not registering the bootstrap
> tools allows to elegantly solve the issue: this way we don't have to add
> complicated rules to decide which packages always need to be present (like
> Debian has to ensure you're not going to remove the kernel package).

Hardly elegant.  RPM or the commercial unices are closer to elegant; *all*
software is managed by the package system.  The word you are looking for
is "simple".

> Now, another problem is, if you install devel/bmake, or archivers/pax, or
> net/lukemftp (etc.), the bootstrap's tools will be overwritten.
...

> IMO, the simplest way to solve the problem is to *not* have redundancy between
> pkgsrc packages and the bootstrap tools. This means removing them from the
> tree, or marking them ONLY_FOR_PLATFORM= NetBSD-*

My fix (and the only correct one, IMHO) is to keep devel/bmake etc current
and compatible.  So I'd suggest the reverse--bootstrap-pkgsrc should go
away and instead be a meta package which is comprised of devel/bmake etc.

/fc