[packaging] Comment #18: package versions
n3npq at mac.com
Wed Jan 7 10:56:52 PST 2009
Good. I believe this comment is headed into LSB 4.0 because
I've been asked to supply some historical context on
LSB (and the tightly but implictly coupled RPM) package "version"
My previous suggestion to LSB re package "versions" can be found here:
and I can dig out older historical LSB package references going back
to 2000 if necessary.
An LSB bug closely related to versioning is here:
The issues of package "versions" have a hugely complicated and
controversial history in LSB as well as RPM (from personal experience),
and I have no reason to think that similar controversies are not
part of APT/DPKG history.
Let's not repeat that history, shall we?
I personally believe that only LSB has a prayer of achieving
a "unification" between the oldest Linux package managers, APT <-> RPM,
which is one (of many) reasons I have tried to participate in LSB.
However, I don't believe that "unification" should be attempted for
until some basic preliminaries are sorted out. I do believe that
the goal of "unification" is achievable through LSB, and should be
clearly stated as such in a package "version" section of the LSB 4.0
Some of the preliminaries include
1) differentiating the "identification" and the "ordering" usages
of package "versions". The "ordering" is far more complicated imho.
2) setting up a framework to capture candidate versioning schemes. For
an obvious example, there is APT/DPKG and RPM identification/ordering.
There are other likely candidates that will need to be accomodated,
including (essentially what The Berlin API does), a '\0' terminated
set of octets for "identification" with strcmp(3) (or equivalent,
and localization have their own very speshul pains) for "ordering"
as a "no-brainer" candidate.
Note that there is no attempt here by me to define or change any
package managers concept of
"versions" in LSB 4.0, only to try to enumerate existing practice
that specification can be attempted, with a later-to-be-determined
goal in mind.
I have (at least) twice before looked at the issues involved in
RPM <-> APT versioning, most recently here
While this work was done for RPM, not LSB, purposes, the results are the
basis of my belief that package "version" "unification" is not only
but also an achievable goal for LSB. I will summarize the results that
I think are
relevant to LSB package "versioning" as I proceed.
And again, its LSB's call, not mine, about what LSB wants to do.
All the above comments are entirely my delusions until I see/hear a
clearer statement-of-work of what LSB
wants to achieve. So honk LSB, not me, please.
73 de Jeff
On Dec 28, 2008, at 6:27 PM, Jeff Johnson wrote:
> A new section "Package Versions" is needed after "22.5. Package
> Naming" at
> Package versioning is nearly as important as "Package Naming" and
> cannot be left
> to packagers/implementations to discover for themselves. All
> installers need "upgrade" specified,
> a package standard that chooses not to specify what an "upgrade"
> means is DOA.
> There are several approaches (see packaging-list archives) and I
> that establishing a "standard" for package versions, with the
> comparison (even strcmp(3) is better than UNSPECIFIED) is perhaps
> the single most important success that LSB packaging might achieve.
> 73 de Jeff_______________________________________________
> packaging mailing list
> packaging at lists.linux-foundation.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4664 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/packaging/attachments/20090107/f14a9cb9/attachment.bin
More information about the packaging