----- [email protected] wrote:
> Shawn Walker wrote:
...
> > So far, we've not had any action attributes that interact with each
> other
> > in this particular fashion, so it seemed simpler to make the cross
> > product of the behaviour visible through the values of the preserve
> > attribute instead of another mechanism.
>
> It's all pretty visible on the action, and although we don't have any
> attributes that modify the behavior of other attributes, I don't see
> why
> that shouldn't be allowed.
>
> > However, I'm open to suggestions as to what that might look like as
> I
> > don't have a good feeling about any particular direction at the
> > moment.
>
> Customizable package:
>
> file path=etc/pam.conf preserve=true overlay=possible
>
> Overlay package:
>
> file path=etc/pam.conf preserve=true overlay=true
>
> Having overlay=possible on a non-preserved file is meaningless
> (linted,
> perhaps, but no install-time effects). An action marked overlay=true
> must
> also be on a preserved file. It is an install-time error for more
> than one
> action of a given name/keyattr tuple tagged overlay=possible to be
> installed. Ditto for overlay=true. It is an install-time error for
> an
> action tagged overlay=true to overlay a file not tagged
> overlay=possible or
> a file not tagged with some form of preserve. An action cannot be
> tagged
> both overlay=possible and overlay=true.
After some thought, this seems like a reasonable refinement. However, perhaps:
Customizable package:
file path=etc/pam.conf preserve=true overlay=(allow|deny|true)
Then the question is, should allow or deny be the default? I guess the
question is whether we believe it's more valuable to not allow overlay of
preserved files to prevent possible accidents, or less cumbersome if we assume
all can be unless told otherwise.
Overlay package:
file path=etc/pam.conf preserve=true overlay=true
One reason I didn't like having the preserve attribute when overlay=true is
that since the preserve attribute is there, it implies that the overlay file is
editable. My proposal actually intends that it cannot be. That is, if you
installed the overlay package, and then edited pam.conf, verify would fail.
The whole point was to have verifiable configuration through packaging.
I suppose I could go farther and say, if you set overlay=true, then we deliver
the file, and verify fails if you edit it, but if you set preserve in addition,
it acts like the original package's preserved file.
> Is there any need for overlay attributes on non-file actions?
Not that I can think of, at least not for the purposes I'm intending.
For non-file actions, the mediated links functionality we've talked about is
likely sufficient (and those are the only other type of action I can think of
where you might want two packages to be able to deliver the same item).
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
