Greetings all,
Tim and I spent some time this afternoon discussing how we want to solve
bug 15842[1] "Allow specifying dependencies in manifests by path instead
of fmri". Here's what we came up with.
We're switching from the term "file dependency" to "incomplete
dependency" because we want users to be able to specify dependencies on
more than just files. Other naming suggestions welcome.
An incomplete dependency has the following required attributes:
* target - This is the file path or service fmri which is depended upon.
If provided more than once, it means that any one of the targets will
satisfy the dependency. (initially file and services will be supported.
If bug 16016 [2] "need to generate dependencies from user and group tags
on actions" is fixed, then manual dependencies for these kinds of
dependencies will also be allowed.
* source - This contains the file or service which needs the target.
(This is equivalent to pkg.debug.depend.reason in generated
dependencies.) This can be specified more than once. Each file or
service provided must be delivered in the same manifest as the dependency.
* kind - This indicates whether the target is a file, service, user
etc... This can only be specified once.
These attributes are optional:
* type - This indicates what kind of dependency should be inferred. If
this attribute isn't set, "require" will be assumed and initially the
only valid value will be "require".
* reason - This contains text explaining why a manual dependency is needed.
The above attributes will persist when pkgdepend resolve transforms the
incomplete dependency into a proper dependency upon a fmri. Pkgdepend
generate will continue to populate attributes that begin with
"pkg.depend.debug".
Open questions:
Do we need to allow users to specify path and basenames separately (like
generate does) or is allowing multiple full paths sufficient?
Can target be a relative path to source?
Should we keep kind, or should target and source just use schemes to
identify the kind of thing they're referencing? Having "kind" seems
simpler, but prevents having files which depend on services, or vice versa
Other items to address:
Pkgmogrify will need to properly handle incomplete dependencies.
Pkglint should check that the items specified in source are actually
delivered in the file with the manual dependency. (Pkgdepend generate
will probably complain/warn/error if this is the case as well, but
checking again in pkglint is worthwhile.)
Pkglint should offer a check that requires manual dependencies like
these to have a reason provided.
If pkgdepend gets an action as input which contains both a fmri and
either source, target, or kind, that will be an error.
We think this structure offers the flexibility we need without imposing
much of a burden on people writing manifests.
Here are a couple of examples of incomplete dependencies:
depend kind=file source=usr/bin/ls target=lib/libc.so.1
depend kind=service source=application/pkg/system-repository
target=milestone/network:default
Thoughts and comments welcome.
Brock
[1] https://defect.opensolaris.org/bz/show_bug.cgi?id=15842
[2] https://defect.opensolaris.org/bz/show_bug.cgi?id=16016
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
