[cc'ed back to tech-install: this overlaps with install issues,
 not  just pkg issues.]


>On Tue, 29 Sep 1998, Jonathan Stone wrote:
>> One of the _really_ important consensus items that we came to then is
>> that the install tools should, by default, DTRT for the naive user.
>> Sure, we can add bells and whistles for experienced users or those
>> setting up diskless/dataless machines, but that shouldn't be the default.

>Sad to say, that's not what pkgsrc does right now. 
>There are several packages that intentionally leave things left over for
>users to do after the pkg_add, although these manual steps could be
>avoided easily. I'm talking of things like editing config files. 

But what pkgsrc does is not necessarily the right precedent, here.
Because this isn't the pkgsrc system!

Perhaps you're overlooking that if we do an OS upgrade of a pre-pkgset
installation, there _is_ no pkg info for the old base-system
install-sets that's being upgraded?  we dont have a pkg database with
the contents of the `previous' release, because it wasn't a package
then!

Take when nfsiod/nfsd moved from /sbin to /bin. Users upgrading from
1.2.x have to manually remove those after installation, or their
systems hung when they started NFS.  the pkg system does deal with
this, yes, but it uses /var/db/pkg (or wherever we move it) to do so.
And (in the case i'm talking about) we dont have that info!

Same basic problem with old, obsolete manpages in /usr/share/man, or
obsoleted headers under /usr/include, tho' they are obviously less
critical.

>Shouldn't be too hard to merge these files into valid PLIST format, even
>with caring for MD/AD/MI/whatever, and then hand this list off to
>pkg_create. 

Yes, exactly.  We just need to carve up the distribl/sets/lists/* into
sensible pkgs.


>>         c) rework the set-untar subroutines in sysinst to look for,
>>          and deal with, pkg-sets. itd be nice if we could handle both
>>            the old sets and pkg-sets for awhile, but not necessary.

>*think* shouldn't be too hard to see if there's a +CONTENTS file at the
>very start of an archive... (yes, the +CONTENTS file is always the very
>first - various pkg_* tools rely on this!).

Uh, I'm talking about a pkg-*set*, not a pkg.  They need not be the
same (tho' it would be very nice if they were).


Pkgs are the pkgs we know and love. (maybe better size info would be
nice, but whatever.)

Pkg-sets are (IMHO) handled by a slightly different tool, the install
tools. From the install-tool end of things, the whole reason we're
using sets of pkgs is so users can decide install all of a set, or to
select individual pkgs from a set.  

That means sysinst (or replacement) needs to parse the pkg-set
contents, and either pop up a menu of what's in it and let the user
toggle which ones get installed; or iterate through them asking the
user "install: yes/no?".  I don think we can do that as part of the
current pkg tools, not least because the pkg system doesn't _do_ that,
AFAIK.  (What does it do with a pkg file which contains another pkg as
contents? Install recursively, or plop the pkg file into the target
filesystem?) And the obvious hook, the pre-install scripts, arent
viable because, for the base system, we have no guarantee that "base
system" commands called by those scripts are already installed!



[[ frills to sysinst or replacement UI ]]

>Fine with me, I'd just like to ask you for one thing:
>check back with the pkgsrc crew before touching anything in
>src/usr.sbin/pkg_* because we have some modifications there going on,
>which we would prefer not to interfer with your chances. Thanks!

Sure, sounds reasonable.  I'm just trying to explain the constraints
from the install side, after all!