Shawn Walker wrote:
> It seemed weird to require that a package delivering a customisation
> for an editable file could specify a preserve attribute and then some
> other attribute that indicated that it was an override for an
> existing, editable file.
Okay, the customization needn't specify the preserve attribute (though it
will make integrating into the current conflicting action handling less
warty).
> 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.
Is there any need for overlay attributes on non-file actions?
I'm not too attached to "overlay"; that's just the way I've been thinking
about the problem.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
