My intent was to extend the already existing storage format from
cfg_cache. For policy properties, we already have:
[policy]
require-optional = False
display-copyrights = True
preferred-authority = updates.sfbay
pursue-latest = True
Why would we use a different format for other image properties?
If the cfg_cache file is replaced with something else eventually, I'm
assuming that the solution will also need to take care of storing this
policy section, the filter section, and the information about
authorities somewhere else too. So whatever that solution is, it could
take care of storing image properties elsewhere too.
Tom
[EMAIL PROTECTED] wrote:
A few comments about this proposal.
We have an existing convention for naming arbitrary property values.
This is used for the attribute action, and is how we store attributes in
a manifest. Check out src/modules/actions/attribute.py for the code.
[attribute]
title = "..."
uuid = "..."
This would instead look something like
<attribute identifier>
name = "title"
value = "..."
<attribute identifier>
name = "uuid"
value = "..."
With both of these issues, the intent is to be able to store some
per-image attribute data, especially for user images. This data
will be stored in the cfg_cache file in a new section:
We intend to blow-up the cfg_cache in the fullness of time. It might be
worthwhile to think about other ways of storing these attributes. Are
you going to have a lot of these things?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
