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
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
