Subject: Re: PLIST content
To: None <email@example.com, tech-pkg@NetBSD.org>
From: Dieter Baron <firstname.lastname@example.org>
Date: 07/02/2006 23:14:36
In article <20060702210644.GB17772@britannica.bec.de> email@example.com wrote:
: On Sun, Jul 02, 2006 at 10:46:24PM +0200, Dieter Baron wrote:
: > In article <20060702153806.GA4648@britannica.bec.de> firstname.lastname@example.org 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
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