Subject: Re: Firewall packages
To: None <bouyer@antioche.lip6.fr>
From: Bernd Salbrechter <bernd@mycity.at>
List: tech-pkg
Date: 09/16/2000 23:33:08
On Fri, 15 Sep 2000 Manuel Bouyer <bouyer@antioche.lip6.fr> wrote:
> 
> On Thu, Sep 14, 2000 at 09:32:06PM +0200, Bernd Salbrechter wrote:
> > Hey wouldn't it make more sense to classify the parts of a package and
> > add options to pkg_add to install only those parts the user wants.
> > Is there some need to strip down the distribution sets also?
> > 
> > I could identify the following part in a package:
> > 1. RUN-TIME: what's need to work with the pkg.
> > 2. DOCUMENTATION: the online documentation, which is nice to have.
> > 3. DEVELOPMENT: what's need to develop other packages using this one.
> >      This will be a superset of "RUN-TIME", but not including
> >      DOCUMENTATION (you can have this somewhere else).
> > 4. CONFIGURATION: default configuration files.
> > 5. EXAMPLES: Files that can be used to give the user some results he
> >      can look on (i.e. tiger.ps in ghostscript).
> >      Should this be split into RUN-TIME, DEVELOPMENT and CONFIGURATION?
> > 6. MESSAGE-CATALOGS: I'm sure not everyone need all languages, but more
> >      than one can be quite common. Dictionaries for several languages
> >      are better handled as separate packages. This will need a way to
> >      install all message catalogs for a set of given languages for all
> >      installed packages.
> 
> Please also add:
> 7. SHARE: all files under the share directory (supposed to be MI and shared
> accros multiple architectures). This can he handy for machines which mount
> share from another one.

Nice that at least one like the idea, but I think that a category
SHARE would not fit into that I have described. I.e. groff macros
will go into SHARE, but are need to use groff so they must in
RUN-TIME.  At the other hand the examples form ghostscript, which
will also go into SHARE, are only EXAMPLES and not need to use
ghostscript.

I can understand the need to separate
  1. Host specific files;
  2. Architecture specific files;
  3. CPU specific files;
  4. Share able files.
But the only solution I can see for the problem is a two dimensional
classification.

As I have written all ready in the answer to Huberts mail, a longer
discussion should take place, before someone start an implementation.

I think user defined parts (as in System V packages) are a bad
idea, it will never be clear do I need that part or not.

Bernd

PS.: Jun Ebihara and David Brownlee what do you think about the
idea (I'm afraid it will break your time line).

PPS.: Do anyone who works on pkg-zing the base distribution can
comment this?