Subject: Re: PROPOSAL: NetBSD System Packages
To: Alistair Crooks <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 10/01/1998 10:38:10
What you say sounds fine to me. I do think some kind of speed is
important, though. Pragmatically, sysinst is a real nightmare to test,
and historically it's been the last thing to get worked on during
releases. We simply _cannot_ let that happen with a merger of the
release(7) sets to be pkg-oriented; we cannot change the pkg_tool
format during a major release BETA, for example.
The way I see it, Jim and Simon and I havea all been saying this:
1. sysinst has a real requirement for "containers" of pkgs, which
we've agreed to call pkgsets. this is a real requirement,
it's not really a negotiable one. meta-pkgs don't meet it,
because when installing from a non-Unix box (DOS, mac, amiga,...)
the user has no way to check dependencies (no pkg tools
to extract them, no tsort to check them, etc.O
2. The sensible approach si for the pkg tools to understand pgksets.
That means both tools can use them. There's an obvious
synergy in having the pkg_* tools be able to do post-install
addition of sets the user initially skipped (e.g., lack of disk
space to stage them during install).
3. We install-side people have described the key functionality
that we need and suggested 2 or 3 different ways the pkg_*
tools could be extended to do this.
4. It's become apparent that we'd be even better off if sysinst
could just _invoke_ pkg_* tools to do all manipulation of pkgsets;
list contents, do full extract, do partial extract.
That way only one toolset knows about the pkgset format; the
pkg* people can rev it as you please independent of sysinst.
(I had thought of a librrary, but is already designed to
fork off existing tools and use them. everybody wins if we
can do that with pkg_* toosl for pkg sets.)
5. Some pkg people are verymis-understanding this request,
in a number of diferent ways:
a) that pkg dependencies (meta-pkgs) are an adequate
solution for install sets. They clearly aren't.
b) as if we're saying the third-party pkgs will have to
use pkg sets. That is not true; it's entirelyup to you
pkg people to decide that,
c) that the introduction of pkgsets for install tools
will force duplication of of multiple coples of
precompiled pkgs where we now use pkg dependencies.
That's crazy; see (b).
d) That the install-side people are forcing two
variant formats and needlessly-diverging toolsets
to handle them. That's crazy; to consider any kind
of `container' mechanism is the only thing driving that.
[I hope we can all show a little more maturity and engineering sense,
and work together to solve this problem.
Alistair: I am reluctant to drag you into this if you don't want to
say anything. But at this point, I'm going to ask for one thing.
Can you commit, in principle, on behalf of the pkg people, to
providing _some_ form of `container' mechanism which the pkg-tools
a) via a @pkg tag in +CONTENTS
b) via +SETCONTENTS instead of +CONTENTS in a pkg
c) a new `pkgset' format -- a tarball with a contents file
-- and a new `set_add' command
c) any alternate mechanism of your design (you're the experts
here after all!)
which need not be used _at all_ by the existing pkg system or pkgsrc,
but which sysinst can rely on to implement pkgsets for our next release?