On Sun, Jul 02, 2006 at 07:12:28PM +0200, Roland Illig wrote:
> joerg@britannica.bec.de wrote:
> >Hi all,
> >here is the initial proposal for PLIST entries.
> >
> >(1) Normal files
> >- path name relative to PREFIX
> >- file content is associated (e.g. in the binary package or the file
> >system)
> >- meta data consists of:
> >  * owner, group, permissions
> >  * checksums (algorithm, value pairs, default SHA1 and RMD160)
> >  * modification time
> >  * optionally triggers
> 
> (1b) Symbolic links
> 
> - path name relative to PREFIX
> - contents
> - owner, group, permissions

I know I forgot something :-)

> (1c) Hard links
> 
> - path name relative to PREFIX
> - path name to link to (must have appeared earlier in the same package)

I'm not sure if we really want this. Hard links are fragile and can
create a lot of problems. Which packages actually use them?

> >(2) Normal directories
> >- path name relative to PRFIX
> >- reference counted
> 
> Is that a boolean field? Or just the information that the directories 
> are reference-counted, but has nothing to do with the PLIST?

It is just a note, see the detailed description later in the rationale.

> >- meta data consists of:
> >  * owner, group, permissions
> >  * NO modification time
> 
> So why don't you just leave it out? :)

Because I want to avoid misunderstandings.

> >  * optionally triggers
> >
> >(3) template-based files
> >- path names can be either relative to PREFIX or absolute (e.g. VARBASE)
> 
> multiple path names?

Scratch the 's'.

> >(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
> 
> Why aren't these just items like in (3) that are registered per single 
> file? If you do it this way, you cannot have differing file permissions 
> for the "files under this directory".

Because we have cases were we can't enumerate the names. E.g. a typical
configuration for Apache would be to put every vhost into an individual
file. I think follow the "best-match-wins" rule is the optimal solution
to cover both cases: /usr/pkg/etc/apache is using (4),
/usr/pkg/etc/apache/ssl.cert using (3). Not a real example, but should
illustrate the point. I want to keep it manageable as well.

> 
> >  * 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.
> >
> >(5) Unmanaged files
> >- like (3), but will always get removed with the package
> 
> Couldn't the cases (3) to (5) be solved with triggers that get all the 
> information they need?

Yes and no. Since they are files normally present either in the binary
packge or the installed version, they should be recorded as such. This
is one of the major problems of the current config file framework.
Second they differ from normal files and directories by not having a
predetermined content and often also having special permissions. Having
to copy them first and change afterwards opens a race which could e.g.
expose a private key distributed as part of a configuration archive.
Last but not least it is necessary to treat e.g. config files special,
since they differ a lot from normal files. Some of the possible user
interactions are mentioned earlier. Having them spelled out explicitly
in form of meta data makes it easier to define interfaces for frontend
programs, which after all have to provide the user input.

Joerg