Brock Pytlik wrote:
2. What is the expected behavior of current software if it encounters
an image with the new file structure? Clearly it isn't going to
work, but will it fail gracefully? Will this change be coupled with
the new cfg_cache format so that the incompatibility will be handled
in the same way? Or, if #1 is implemented, could there be a switch in
the configuration that allows the old layout to continue to be used
until there is an explicit decision to use the new format?
I don't know, and there's not much I can do here. My guess is it will
chug along fine, but you'll end up with duplicate information on disk
stored in two different file structures. Essentially, the old code
won't know where to look for the new files, and so will download them
again. At best, the duplication will remain until the file(s) is/are
removed.
I'm not inclined to make this a user tunable item, both because a user
shouldn't ever need to care, and because the existing behavior is
fairly pathological. If you can make a compelling case, I'll listen.
Actually, the behavior that you describe doesn't sound too bad. The
image doesn't get corrupted, and the only downside appears to be extra
download time and extra file system spaced used.
The standard list of reasons for preserving compatibility at the image
metadata level includes:
- whole root zones, where the local zone doesn't have the same version
of pkg(5) as the global zone
- user images mounted on NFS file systems, where one system doesn't have
the same version of pkg(5) as another
- user images on non-OpenSolaris systems that have an embedded version
of pkg(5), and people use the version of pkg(5) from one image to manage
another image.
Thanks.
Tom
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
