[packaging] Comment #18: package versions

Jeff Johnson 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  
LSB 4.0
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  
Core packaging.

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  
"unification" of
RPM <-> APT versioning, most recently here
and also
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
> 	http://dev.linux-foundation.org/betaspecs/booksets/LSB-Core-generic/LSB-Core-generic/pkgnameconv.html
> 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  
> believe
> that establishing a "standard" for package versions, with the  
> necessary
> comparison (even strcmp(3) is better than UNSPECIFIED) is perhaps
> the single most important success that LSB packaging might achieve.
> hth
> 73 de Jeff_______________________________________________
> packaging mailing list
> packaging at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/packaging

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/packaging/attachments/20090107/f14a9cb9/attachment.bin 

More information about the packaging mailing list