On Wed, 30 Sep 1998, Jim Wise wrote:
> I originally looked at the possibility of package sets being meta-pkgs,
> and I'm not convinced it's a good idea.  The main problem I foresee is
> that users will want to be able to remove a package set at a later date.
> Removing a meta-pkg doesn't accomplish this, and it's not clear to me
> that it should.

Yup, you're right... maybe we could add an option to pkg_delete to go
recursively down for all depending pkgs, and nuke them unless they're
needed by something else (bottom up, probably). 

Please note that there's nothing special about the pkgs in "meta-pkgs" -
these are just normal pkgs that do have other packages as dependencies
(which may in turn depend on others again ...). Maybe we should clarify
what we're talking about first. .-)


> Another concern about meta-pkgs is that several people, most recently
> Jonathan in his summary of past discussion on this issue, have requested
> that the system still be distributable as a relatively small number of
> files, which can be downloaded and verified easily by hand.  Package
> sets are designed to be containers for well defined groups of system
> packages, and will meet this requirement.  In contrast, if I download a
> meta-pkg, I am left guessing as to what other packages I need to
> download until I actually unpack the meta-pkg and try to install it.

Not really. Right now you can query the pkg's PLIST (+CONTENTS file) with
"pkg_info -f", and adding some option to only print the @pkgdep lines
shouldn't be to hard either (or to dig them out from some program that
uses that kind of inforamtion).

With that kind of information, you can descent again into a pkg and get a
list of all the needed dependencies. (Right what "make
print-package-depends" does in source now :).


> >> I think that means we want an idea of the total size of each of the
> >> sets (not pkgs) before we start unpacking them.
> >
> >You need the set sizes, but they should be (IMHO) calculated at runtime,
> >so the one mainting a pkg doesn't have to recreate a pkg-set just because
> >he updated that pkg.
> 
> By `runtime', do you mean package build time or package install time?

for sets: package install time (summing up size information from
          +CONTENTS files).
for pkgs: package build time (summing up file sizes and putting
          information into +CONTENTS file).


> If you mean package creation time, I agree strongly with this.  IMHO,
> the only information that should need to be put together in creating a
> set is the names of the constituent packages.  All other information
> (package comments, mainly, and package sizes if our package format is
> modified to provide them) should be generated dynamically from the
> packages when the set is built.  This information _should_ be stored in
> the generated set file's contents file, however.

Why? This would mean another place where information is stored, and which
needs to be maintained if a pkg of the set is updated. 

I mean: note the size of a pkg at it's build time IN the package, and 
then be done with it. Noe if someone comes up and wants to install some
"set" which happens to contain that pkg, fine, ask the pkg for it's size
and add it up.

(You still seem to like the idea of a "pkg set" being something different
than a regular pkg, while I'd prefer to add this functionality into what
we call a "pkg" now. It's just that in pkgsrc terminology, it's "pkg"s and
"depending pkgs" instead of "pkg sets" and "pkgs").


> If you mean install time, I'm not sure that's a good idea.  I don't see
> why we should do an expensive set-grovelling operation at install time
> to determine information which will have to be available at package
> creation time anyhow.

Well, I'm concerned about the cost of the groveling as well, but we'll
have to see if we can't cache this somehow later, maybe in some file
(that's what you then call a "pkg set", maybe). 

And for the size information being available at package creation time: I'm
not sure you want to re-create the pkg-set (in pkgsrc lingo: pkg having
a dependency on the updated pkg), e.g. you don't want to re-create the
kde-pkg just because there's a new kde-base-pkg. (pkg_* will soon support
wildcard dependencies, this the kde-pkg can depend on kde-base-*, and thus
the kde-base-pkg can be updated to another arbitrary version without the
kde-pkg getting invalid; similarly, this allows people to update xpm,
lesstif, etc. without any depending pkgs breaking). 


> >BTW, this size thing should always be displayed, even when offering a list
> >of pkgs to select, so a user can (also) use this information to decide if
> >he wants that pkg at all. 
> 
> BTW, if we design system packages so that none install into more than
> one of /, /usr, /usr/X11R6, and  /usr/share, it _should_ be pretty easy
> (on most common system configurations) to see if you have room for
> something simply by looking at the size of the actual package file -- or
> am I missing something?

No, but you need to display that information in the list of packages
available for installation.

And yes, supporting only one of /, /usr, ... (i.e.: everything in one
@prefix, without any @cwd commands in the PLIST/+CONTENTS file) seems very
desirable not only for this. 

*think* Then again, there will be pkgs that also want to write somewhere
else, think about things modifying /etc-files. But that might be handled
by some CLUEFUL.sh script then, that does any work left outside of
@prefix. (see other mail .).


> >[*] You can put size information either in the +CONTENTS file or into
> > another +-file, each of which has several advantages and 
> > disadvantages: 
> > ...
> I think that this decision is beyond the scope of system package design,
> BTW.  Whatever decision is made by the pkg-tools team will be reflected
> in the system packages, as they will be using the same tools as pkgsrc
> uses.

Well, "the pkg-tools team" would be glad for your input there (or whoever
will do the UI)... but this should probably be fleshed out in another
mail (It'll be probably arranted around pkg_info, plus adding some
option to it). 


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>