Stephen,
The python UUID module[1] is a separate deliverable in 2.3 and 2.4 (it's
included with python in 2.5). It's distributed under the Python
software license.
Assuming it's ok to bring that dependency in, should this be in a
separate package (like cherrypy)? It's only a single file (uuid.py). If
not, would it just be dropped in /usr/lib/python2.4/vendor-packages?
Is there any expectation of moving to python 2.5 for other reasons soon?
Thanks.
Tom
[1] http://pypi.python.org/pypi/uuid
Stephen Hahn wrote:
* Christopher Kampmeier <[EMAIL PROTECTED]> [2008-05-17 03:23]:
Stephen Hahn wrote:
* Tom Mueller (pkg-discuss) <[EMAIL PROTECTED]> [2008-05-16 15:53]:
Here is a proposed design for the following issues:
1347 optional UUID per image
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:
[attribute]
title = "..."
uuid = "..."
The pkg command will be modified to support new subcommands:
pkg set-attribute attrname attrvalue
pkg attribute [attrname]
Setting an attribute to an empty value, i.e., pkg set-attribute title
"", would cause it to be removed from the cfg_cache file. The "pkg
attribute" command is for printing out the values of image attributes.
These subcommands are intended to mimic the authority related subcommands.
pkg unset-attribute, please.
The image-create subcommand does not set any attributes by default.
The uuid attribute, if set, would be included in the user-agent value of
all requests to the repository. The format would be as follows:
uuid cannot be an image-wide attribute.
Why not?
Because it allows correlations between repositories that some sites
might find unacceptable.
It must be a per-authority attribute.
Perhaps you're thinking of a different use case that also warrants UUID
at the authority level.
In our unbundled/layered distro use case, binary distros already contain
logic in their initial installers or other code to instantiate service
tags outside of the process of establishing or using IPS user images.
These service tags include a UUID. Since often the binary being tagged
equates to the overall distro, it makes sense in our use case to reuse
the already defined UUID of the service tag as the UUID fore the
associated IPS user image.
If your user image only connects to one authority, then whether it
lives on the image or its sole authority doesn't matter.
(That is, it's different.) I also don't think "pick your
own UUID" makes any sense. I'd rather see
pkg set-authority --reset-uuid authority
pkg set-authority --unset-uuid authority
to have a UUID generated or removed.
It certainly would be nice to support options for both supplying an
existing UUID and asking pkg to create one.
I don't think so. If you allow the editing of a UUID, then its
universally uniqueness property is weakened. Introducing a UUID is to
allow discrimination between images, not to encode some fingerprint of
an image's contents.
- Stephen
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center/OpenInstaller Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
