William Schumann wrote:
> Dave Miner wrote:
>> William Schumann wrote:
>>
>>> Stephen Hahn wrote:
>>>
>>>> * Dave Miner <Dave.Miner at Sun.COM> [2008-03-06 22:12]:
>>>>
>>>>
>>>>> Stephen Hahn wrote:
>>>>>
>>>>>
>>>>>> Watching this discussion proceed, I now feel that this file should
>>>>>> either be removed and a small C API be written to query the packaging
>>>>>> metadata (which has all the appropriate information in the convention
>>>>>> that the product will use to describe what's installed). I have not
>>>>>> seen nearly enough description of what questions are being asked that
>>>>>> this file/interface is supposed to answer, and what entities are
>>>>>> asking these questions and under what circumstances.
>>>>>>
>>>>>>
>>>>> There was some fairly cryptic stuff in the initial mail William sent,
>>>>> but it basically boils down to the installation and software
>>>>> management utilities being able to identify and present to the user
>>>>> what's installed in the disks and partitions attached to the system.
>>>>>
>>>>>
>>>>
>>>> That would explain a file with a single text string (like "SunOS 5.x,
>>>> Distro xxxx, i86pc"). A general name-value store is excessive; as a
>>>> bonus, the library API would to a single function.
>>>>
>>>>
>>> The name-value store assured that it could be parsed, and made clear how
>>> a release was identified, field-for-field.
>>> If you have it as a single string in a file, it would have to conform to
>>> a syntax so the release number could be extracted.
>>> I have no problem with representing it as a single string, as long as it
>>> did not degenerate to something that could not easily be parsed by a
>>> program.
>>>
>>>
>> The point is that the need to parse it should no longer exist, as all
>> we'd be after is a displayable name for users. From the tools point of
>> view, package versions are what matter.
>>
> This sounds fine to me.
>
> So, INST_RELEASE would remain, but only to give a single version string
> for display only.
Before proceeding here, please discuss with Lori whether this file is
used by the ZFS installation project, and how invasive it would be to
remove it.
Dave
> For convenience, for each new Solaris build, a single C function call or
> script could assemble the string and create the file:
> set_release_info(
> char *path_to_output_file,
> char *os, ("Solaris")
> char *major_version, (11,"Indiana")
> char *update, (release number - could be suffixed with "beta", "fcs")
> char *build_ID (79a)
> )
> INST_RELEASE would be delivered in package SUNWsolnm, and
> set_release_info() prepares it for packaging.
> Any release version information needed in the future would be taken from
> the package containing the component of interest.
> William
