On Jun 21, 2008, at 9:50 PM, Wichmann, Mats D wrote:

>
>> LSB has chosen to leave "upgrade" UNSPECIFIED,
>> and has also chose in the "Berlin API" to ignore the
>> fact that both dpkg/rpm versions are a triple of
>> Epoch/Version/Release.
>>
>> Pretending that a "version" string can be anything, opaquely handled,
>> including E:V-R, or something else, misses the
>> issue that "upgrade" based on "version" is undecidable
>> until "version" is well formed, and a collate sequence
>> is defined for "upgrade" comparison.
>
> the absence of any description of what "version" means
> is a bug in LSB, whether or not that issue is picked
> up by the Berlin proposal.  upgrade is a little dicier
> in the LSB sense, as it seems different packaging systems
> may do quite different things here. Responding to that
> by pretending upgrades don't exist is the cowardly
> approach, I know...
>

Leaving "version" as an unspecified opaque string, but
pointing out that there are two obvious example usage cases,
dpkg & rpm, that have chosen to use E:V-R, would seem
to take perhaps 4 paragraphs (maybe 2 hours of work)
in a document.

Similarly, "upgrade" can be left to the installer, with the
obvious candidates of dpkg & rpm used as examples,
and suggestions about ISO major.minor.micro versioning
Suggested/Recommended as sensible.

For extra credit, add the glibc vercmp routine as an LSB API and
a 3rd alternative collation sequence for "upgrade", so that _BOTH_
rpm & dpkg fan boys have something to rant about.

And the above is tho no-cojones wussy wriggle room solution.

Any movement whatsoever is preferred to the frozen LSB deer staring
at the approaching vendor distro headlights ...

73 de Jeff