In article <20060702210644.GB17772@britannica.bec.de> joerg@britannica.bec.de wrote:
: 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.

  For deletion/archival, I think this is okay.  For installation
(copying over from share/examples), I think it's not.  So if all
``include files'' that get installed by the package must be listes as
(3), and (4) lists directories where the admin may place additional
``include files'', I'm happy with it.

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

  I don't care about the details, just that we are able to handle
normally installed files that can change.  So, that is fine with me.

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

  True, user/gruop creation is special.  Okay, let's keep them
separate.

					yours,
					dillo