[pkg-discuss] New layout for download cache and files directory for depo

[Tom Mueller (plain-text)]

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