Mirrors are attributes of authorities, so I wouldn't expect to see
set-mirror and unset-mirror subcommands. Rather, the set-authority
subcommand should be modified to deal with mirrors.
I would agree with questioning the relationship between image policies
and properties. For example, the preferred authority is currently in
the policy section but I would argue that it belongs as a property.
Maybe all policies should really be properties and we should get rid of
the policies section. However, I was trying to implement this feature
without unnecessarily touching the existing design. If desired, I can
certainly recode this to get rid of the policy section and just include
them with properties.
WRT this being "bolted on", the idea of having image properties
(previously called attributes) has been in the doc/image.txt file for
quite some time (at least since last December). The functionality that
image.txt referred to was just never implemented. Maybe I'm not
understanding what you mean by bolted on.
Tom
Dan Price wrote:
On Wed 02 Jul 2008 at 02:57PM, [EMAIL PROTECTED] wrote:
Tom,
The design spec for this feature, as discussed previously on
pkg-discuss, is contained in the issue:
http://defect.opensolaris.org/bz/show_bug.cgi?id=856
I really don't think this design is complete. It looks to me like
somebody said, "We need an image title." Then the entire property
interface was designed around that.
It seems like we ought to be able to unify the property space to
encapsulate all of the different image configuration options as
properties. Aren't authority, filter, image-policy, and mirroring
options all properties that are specific to an image?
This design just adds another set/unset/<name> triplet which is only
going to get worse as we add more features to the configuration. If you
put this back, and I follow up with mirroring, we'll have:
set-authority
unset-authority
authority
set-mirror
unset-mirror
set-property
unset-property
property
This isn't a very usable command-line interface. As we add options to
the config, it'll only get worse.
I have concerns here too: this looks to me a bit too bolted-on.
Users might reasonably regard lots of different things about an
image to be a "property" of the image-- it's path, it's preferred
authority, it's list of authorities, etc. Whereas the proposal
is sort of a way of adding window-dressing to an image.
That is to say, the proposal's claim to the name "property" seems
over-broad given the extremely limited scope of this facility.
Whether the set-, unset- etc command pattern is a good UI paradigm is
perhaps a good discussion for another time.
As a side issue, I really think that we need to expose the cfg cache
object as a first class thing, and stop adding methods to Image which
just pass through.
-dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
