The installer will create INST_RELEASE with current version and build
information through calls to set_release_info(char *root_directory,
field, value); The same goes for any in-place upgrades.
Upon successful completion, 'pkg image-update' will update INST_RELEASE
Solaris version calling set_release_info("/", build and version...).
This will require it to fetch the Solaris version and build ID from the
remote source. It's unclear what 'pkg image-update' should do in this
case if it fails to update some packages.
Target Discovery will use get_release_info(char *root_directory, char
*field) for each Solaris instance it discovers, and report the info to
the installing user.
William
Dave Miner wrote:
> Bart Smaalders wrote:
>> Dave Miner wrote:
>>> Bart Smaalders wrote:
>>>> William Schumann wrote:
>>>>> For this, I propose:
>>>>> MICROREV=<microrev> (optional)
>>>>> and
>>>>> FULL_VERSION=VERSION.REV[.MICROREV]
>>>>> where <microrev> is <micro revision number>[a | b | ...]
>>>>>
>>>>> Your example would be FULL_VERSION=10.2.6b
>>>>>
>>>>
>>>> Could you explain how this file will be kept up to date
>>>> if the installer is only ever run once, and all subsequent
>>>> updates to the system are run w/ pkg image-update ?
>>>>
>>>
>>> I thought the proposal said the file would be delivered and updated
>>> by SUNWsolnm.
>>>
>>> Dave
>>
>>
>> Maybe I missed something.
>>
>> From a previous mail on this subject:
>>
>>> Functions to manage INST_RELEASE during install include:
>>> int set_release_info(const char *field, const char *value);
>>> char *get_release_info(const char *field);
>>> int write_release_info(const char *root); writes INST_RELEASE
>>> according to current settings.
>>> void dump_release_info(void); write to stderr
>>> etc.
>>> These functions are to be made available in a library in the
>>> SUNWsolnm package.
>>
>
> Or maybe I inferred too much. William will need to clarify...
>
> Dave
>
