On Wed, 30 Sep 1998, Jonathan Stone wrote:
> Um.  I think maybe this _does_ overlap with pkg formats, at least if
> we want to use the identical same format for pkgs and pkg-sets.

I'm quite sure we want. We have in pkgsrc/meta-pkgs already an attempt of
doing some, as does our kde and probably some other pkg. Offering another
UI for installing sets doesn't make much sense to me as people will have
to know what they want ("I want to install the kde pkg - oh, it's a
pkg-set..."), plus the information you put (probably manually) into
pkg-sets should be calculated as easy as possible - think about if you
replace one pkg of the set, you sure won't want to update more places as
necessary - and if you can query the size of 1 pkg, you can go down
recursively for all depending pkgs, if you want - and voila, there's your
size of the hole pkg. 

(As I've said, I do have some code for this that even works over FTP; if
just has to be beaten into going recursively into dependencies, which
shouldn't be too hard)


> I'm not sure if its possible to accurately check pkgs or pkgsets for
> disk-space constraints, short of unpacking the pkg and checking
> _every_ file (who knows how much symlink/NFS damage a sysadmin might
> do under /usr?).

Unpacking a pkg before installing it just to check size? Forget it -
unpack emacs on a vax or m68k, and you know what I mean. (That's why I say
put it into +CONTENTS or so[*]). 


> On the install side the case we care about most is the naive users,
> and itd be very nice to warn them if their disks arent quite big
> enough for the sets they've chosen.  Ideally we'd want to do that
> before unpacking the basic `base' set, so the user can resize
> partitions and start again without too much trouble.

Hehe, as if that resizing was that easy. B-)


> 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.


> And the compiled-in lists of files, and _particularly_ sets split itno
> floppy-images is one of the nastiest things to get right in sysinst.
> (we dont always know for sure now many floppies a set will take until
> after the BETA gets frozen.)  So It'd be nice if we could wrap up the
> "meta-info" in a file that sysinst could read in and parse, rather
> than compiling it all in.

Compiling-in is not an option at all.
Reading from a file is nice, but see above for my doubts about what
happens if a pkg gets upgraded.
Generating this information dynamically at runtime would probably be best,
at least most accurate. Speed may be an issue here. 


> I'm thinking of something sort of like a PLIST, but for the entire
> contents of a reelase(7) binary/sets/ dir. It'd describe what pkg-sets
> files are there, whether they're "optional" (installation can be
> toggled off by the user), whether they're split, and if so, how many
> split files to look for. _and_ how big they are.

Er, what's a "pkg-set file"? single pkg?


> (We probably want compiled-in defaults just to be safe, but being able
> to over-ride them sounds like a win to me. You could do a
> minor-release upgrade via FTP just by running your old sysinst from
> single-user, giving it the new release number on the command line...)

And fail if someone upgraded something ...

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. 


 - Hubert

[*] You can put size information either in the +CONTENTS file or into
    another +-file, each of which has several advantages and
    disadvantages:
 
    +CONTENTS: 
      + can be retrieved even over FTP
      - slow if you want to dig out size from locally installed pkgs
      + code for this exists :)
    +SIZE:
      + fast if you want to find out size of a locally installed pkg
      - can't be easily retrieved from FTP-pkgs (pkg_add ftp://...),
        at least not without some major beating to pkg_*. 
      + Code cor this is in FreeBSD.    

    If you ask me, I'll vote for +CONTENTS.

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