On 06/12/12 17:39, Edward Pilatowicz wrote:
On Fri, Jun 08, 2012 at 01:16:15PM -0700, Brock Pytlik wrote:
On 06/08/12 06:49, Mike Gerdts wrote:
On 06/07/12 22:13, Brock Pytlik wrote:
[snip]
In all of the above, it seems as though you aren't using image
names, rather you are using zone names. -Z evokes "zone". Thus,
it shouldn't be "root", it should be "global". This avoids the
problems associated with a zone named "root".
That does bring up another issue. Is there intent to allow user
images to be linked to a system image? If so we probably need a
way to distinguish between user images and system images because
user images are unlikely to be participate in this scheme that is
clearly aimed at zones.
No, I actually do mean image names. I'm not sure what about the
names implies they're zones and not images. If it's that they don't
all begin with "system:" or "linked:" or whatever the tag is, my
hope was that we could make an educated inference about what kind of
image they meant 99.9% of the time, and not make them type the same
prefix over and over and over.
we can allow for convient aliases assuming there are no duplicate
matches. ie, linked image name 'foo' could be mapped to zone:foo
assuming that there are no system:foo images. (early on in the linked
images code i used to do this, that functionality got lost during some
internal re-write.)
It would probably be nice to be able to wildcard with image type as well to get
all zones via zone:* but ignore other child images.
We haven't even decided what a user image is, so I don't know at the
moment whether or not they'd participate in such a scheme. My
complete guess is that any child image in a "push" relation to the
parent image is a valid option with -Z (or whatever character we'd
like to choose instead), and no "pull" images would be. I also don't
really care whether we use "root" or "#ROOT#" or __ROOT__ or any
other random combination of characters that can't be a zone/image
name.
i always assumed that we'd support some kind of user linked image, and
if we do your assumption about include "push" children is correct.
as we discussed earlier, i kinda like the idea of having "root", since
that also corresponds to the pkg -R option.
ed
I don't see how pushing system software into a user image makes sense. Perhaps
my understanding of a user image is just way far off from what others expect. I
had expected that a user image would be used for packaging software in a way
that it didn't have to live in the BE. In such a case, the only useful
interaction between a system image and a user image would be parent dependencies
to say myappserver (installed in a user image) requires openssl@mumble in the
parent image. Push the system openssl into the user image would not be terribly
useful unless it used and RPATH of $ORIGIN/../lib and had similar mechanisms for
finding configuration files, certs, etc. within the user image.
I'm not so sure that there's benefit in reworking all of Solaris to work nicely
in the type of user image I've always envisioned. It seems as though others
view user images to be much more like system images. Is that correct?
--
Mike Gerdts
Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
