Subject: Re: is there still need for devel/bmake and devel/mk-files?
To: None <firstname.lastname@example.org>
From: Frank Cusack <email@example.com>
Date: 06/08/2003 01:23:54
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
> 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.