On Sun, Jul 02, 2006 at 10:46:24PM +0200, Dieter Baron wrote:
> In article <20060702153806.GA4648@britannica.bec.de> joerg@britannica.bec.de wrote:
> : (4) template-based directories
> : - path names can be either relative to PREFIX or absolute (e.g. VARBASE)
> : - meta data consists of:
> :   * owner, group and permissions
> :   * owner, group and permissions for files under this directory
> :   * owner, group and permissions for subdirectories
> :   * template name (empty directory assumed if missing)
> :   * optionally triggers
> : - similiar to (3), but considers the entire subtree as configuration
> : item. useful e.g. for Apache which uses multiple subfiles by default.
> 
>   What exactly are you trying to solve with this?
> 
>   If it is installing multiple config files from share/examples, I
> don't think it's a good idea: config files are important enough so we
> should take the trouble to spell out what gets installed.  It's too
> easy that an update adds an example script in that directory that
> should not be installed.

As I tried to explain in reply to Roland, I'd like to handle the
situation of mmodular configuration files as much as possible. Many
daemons and other programs have some kind of include mechanism which
allows splitting large configuration files into smaller pieces. When we
want to be able to gracefully handle configuration files, we need to be
able to deal with it, so that they can all be archived / deleted in
unison. Requiering them to be kept in the subtree is a good compromise
which reflects what most users do anyway.

One target audience is automatic deploiment. E.g. for a DNS server two
components are needed: the binary package and the configuration archive.
When I can allow this with generic frontends on top of pkg_add, I gain
some useful functionality, IMO.

> : (5) Unmanaged files
> : - like (3), but will always get removed with the package
> 
>   We will also need to handle the case of files that are normally
> installed but can change.  Maybe a flag (nocheck?) that can be added
> to (1) and (3)?

The difference of (1) and (3) is that the first category has a
pre-defined content is supposed to be static. It also gets removed with
the package. Unmanaged files would fill directly between those two.
It might be a good idea to make the template entirely optional for them,
e.g. when a real install script is used to create those. A good example
is compreg.dat in the mozilla packages. Another example
etc/fontconfig/fonts.conf.

>   Also, you put most of the information used by the INSTALL/DEINSTALL
> framework into the PLIST.  The only thing left that I can think of are
> users and groups.  While not files, what about putting them here, too?
> As triggers without pathname.

The question is whether we can think of any other
pre-install/post-deinstall actions. As long as user and group creation
are the only actions which are required to run before the package can be
installed or after the package was removed, I would keep them special.
This makes sense for larger installations as well, since it is easier to
handle users like another description line and create them before
installing a bunch of packages. I mean Roland's paranoia mode, which
would ask first whether the following users/groups should be created and
not in the middle of a long installation.

Joerg