Tom Mueller wrote: > [EMAIL PROTECTED] wrote: >> Do we have a customer use case where a per-authority UUID is okay, but a >> per-image UUID isn't? >> > I'll need to have Stephen chime in on this one. I was under the > impression that when he said "Because it allows correlations between > repositories that some sites might find unacceptable." that this was > based on real customer use cases. > >> One of the comments that Stephen supplied in this thread was that the >> UUID should be opt-out, not opt-in. >> > I'm expecting that this will be handled by an installer. A UUID cannot > be set for a pre-installed image that is copied from a CD or downloaded > because then everyone would have the same one. So it has to be set by > the installer (by calling --reset-uuid). That part will be automatic, > and to opt out, someone can run --unset-uuid.
Still, in cases where a user creates an image for his own use, it would be a lot nicer for the image-create to automatically set the UUID. Otherwise, any time an image-create is performed the user would have to execute another command to set the UUID. Since that won't happen very often, the community will lose the ability to sufficiently learn from the operations associated with image. Can we learn from how VirtualBox and other "image" management tools such as VMWare handle UUIDs, copying and cloning? It's a very similar situation. For example in [1] below there's discussion of UUID management for a VMware image: "You should not edit the .vmx file to change the UUID or MAC address, since just the fact you moved the virtual machine. You will be prompted to create a new UUID when it is powered on. Since the MAC is based on the UUID, this will also create a new MAC address." It seems like even IPS itself could sense movement of an IPS image and force a UUID reset or unset automatically. Failing that, image management tools such as an installer could force a reset. Chris [1] http://communities.vmware.com/thread/37361 _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
