Subject: Re: PROPOSAL: NetBSD System Packages (LONG)
To: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>
From: Jim Wise <jwise@unicast.com>
List: current-users
Date: 09/30/1998 18:03:51
-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 30 Sep 1998, Hubert Feyrer wrote:

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

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.

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.

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

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.

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.

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

>[*] 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.

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.

- -- 
				Jim Wise
				jwise@unicast.com


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQEVAwUBNhKqzYkLDoBfn5jPAQGecwf7BHPk5aMdEws/ZDyd1PbcQgq8o26wruhP
BlZuBDculcNMO8xXahVUkgZvzStw2JtO/4i7sZMKn44TUpDNyXkM0tBzK/44Kfpf
Xkhs7uoPWlzzCi8CyAgBgjxxA+9uJyHdBMN0FEd5eaT0bzO4sv1V9VJwi6DBbx4x
BmX6q6gajMBFWeKNBA/wMo6NAikJP1zslVK8yUx3cjGGH0kT8PqOXdQ1DbhhnZH+
RUNYAWH0sEUbBk9KhhAwkVAzMlujOpHKRqz3llmWdb5ao4wLy9hUlWOAdgbSl7yh
SxxcfnQp0G+PEuqwyjqrau5WRlw/v434w06FYbwQWbrfN6LS5Z/bIQ==
=i4Qe
-----END PGP SIGNATURE-----