On Wed, 30 Sep 1998, Jonathan Stone wrote:
> Once you accept the requirement for pkgsets with the same granularity
> as our existing sets, acually containing copies of the constituent
> packages rather than pointers to them, then all the questions  pretty
> much fall into place as Jim has anwered them.

Well, OK, understood.
You're out of luck with the existing tools for the "include copies" (over
"contain pointers") approach then, though.

My hope was to get one interface for both "system"-pkgs and pkgsrc-pkgs so
then-existing UIs can both install them without knowing which is which.

BTW, if you really want to do the "include copis", you'll have to make
base.syspkg, text.syspkg, comp.syspkg, etc. plus one all.syspkg - is this
really intended?


> I'd replace the existing makeset / makeflist/checkflist with a new
> "makeset" script which makes pkgsets instead of tarballs.  The makeset
> arguments would not change.  The sets/lists directories would be
> replaced with, say, a directory tree, one dir per pkg in a set.
> 
> Each directory would have partial PLIST files for:
>      * MI,
>      * AD
>      * object-fmt dependnet
>      * MD 
> 
> plus a script to create the PLISTS and check the contents exist in
> $DESTDIR.  We'd compute the sizes of each pkg when the pkg is built.
> At set-creation time we'd, add installed-size of all pkgs in a set to
> get the installed size of the whole set.
> 
> I hope we've reached consensus on that much.

Basically that's ok... but maybe see my all.syspkg vs. base.syspkg etc.
question above - how many different "pkg set"s do you want to create?


> I'm afraid I dont understand why you make a distinction bewteen
> +CONTENTS and +SIZE.  What's the difference?  Is one available via FTP
> separately from the actual pkg file?  If it is, we can make the
> +SIZE available too.

First, keep thin information in one place, to avoid redundant code to
maintain it, and apply the principle of "least confusion". 

That said, and still assuming that you WILL use the current "pkg set
contains a pointer instead of a copy" scheme, the distinction basically
boils down to the question: do you want to be able to use pkgs that are
installed via ftp (i.e. the pointer goes behind a ftp://-link), or do you
want to be able to sum up size of *installed* pkgs fast. 

For the installation system, i think the further is more interresting.  
But YMMV, and I won't say I have that much of an opinion here - tell us
what you want. :)  (IF you want it at all - see "pointer vs. copy" above).


> If not, what _is_ the difference?  If there's a special frob to FTP a
> pkg to stdout and snarf out the first file from the stream (and then
> close it without waiting for the rest), then we can mandate that +SIZE
> is the secnd file and do another frob to sarnf out the _second_ file,
> too.  I genuinely don't get it. would you mind explaining, please?

Well, adding this code to pkg_* make it not look nicer, that's all.  I've
tried to understand that code during the last weeks and added some things,
and adding +SIZE for every option won't make things more fun (pkgs can be
installed via stdin, e.g.).


 - Hubert

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