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

(1c) Hard links

- path name relative to PREFIX
- path name to link to (must have appeared earlier in the same package)

> (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?

> - meta data consists of:
>   * owner, group, permissions
>   * NO modification time

So why don't you just leave it out? :)

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

multiple path names?

> - meta data consists of:
>   * owner, group, permissions
>   * template name ("/dev/null"  assumed if missing)
>   * optionally triggers
> - on installation time, the template is copied to target name, if
> missing. alternatively an archived version might be restored. on
> deinstallation time, the file is either removed (when unmodified),
> archived (modified) or left in place.
> 
> (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".

>   * 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?

trigger directory(pathname, user, group, permissions)
trigger managed_file(pathname, template_pathname, user, group,   \
         permissions)
trigger unmanaged_file(pathname, template_pathname, user, group, \
         permissions)
trigger shell(pathname)
trigger user(username, groupname, uid, gecos, home, shell)
trigger group(groupname, gid)
trigger rcd_script(pathname)
trigger info_dir(pathname)
trigger font_dir(pathname, font_type)

The pkg_install package would then install its listeners for these 
triggers, which would do the necessary things.

Roland