[lsb-discuss] RPM decision process

Jeff Johnson n3npq at mac.com
Thu Apr 17 07:09:17 PDT 2008


Several "facts":

The "LSB format", which used to be called RPMv3 format because of the
value in byte 5 of the rpmlead, is exactly the same as the RPMv4 format
because the value in byte 5 of the lead is still 3.

Which is why you can't find documentation about "RPMv4 format". The  
format
(I will get to content and usage next) has not changed.

The content (i.e. the tags) have changed. The most significant change
was (in ~2000) representing absolute file paths as a triple, not a  
string.
That is been finessed (as in "permitted") with the LSB packaging doco
and tools for several years.

There are a handful of additional tags that have been added over the  
last
9 years. Many of them have already been added to the LSB packaging spec.
There's a few additional changes that I have known for years and most  
recently
checked in January 2008. The LSB task at the "content" level is to  
decide
whether tags are mandatory or optional, and forbidden or permitted.

At the package "usage" level -- i.e. how tags should be used by an  
installer --
LSB has never attempted any working definition AFAIK. That means the  
"usage"
case if, say, RPMTAG_POSTIN which you are seeking is UNSPECIFIED.

Ther are additional subtleties if LSB wishes to attempt to  
"uplift" (or not)
to what you are calling "RPMv4" format. In fact, the format/content used
by RedHat and SuSE is diverging because the 2 vendors have chosen
different approaches to multilib packaging. The divergence has a direct
impact on your ISV customers, who wish to distribute software on vendor
platforms. The additional subtleties involve specifying sort orders  
for metadata,
and version comparison and other issues.

And since Ted T'so has chosen to insinuate that Russ (and my) intention
is to advocate "rpm5.org technology" adoption for LSB, that is plain  
and simply
not the case.

I have offered to write tools (like rpm2lsb) for conversion; I have  
not said what
language would be used, nor anything else about how the tool would be
written. In fact, I have seen no detectable interest from LSB in a  
tool that converts
existing vendor packages to "LSB format" packages, and so have not
wasted time on writing rpm2lsb. I have written the tool several  
times, it
just isn't hard.

I have offered to help document the differences (as I know them, and  
I know them
well) amongst existing vendor usage so that a standard could be  
attempted.

There has been no detectable LSB interest in my offers. I am  
obligated to
provide information about RPM, its a duty. Whether LSB wishes assistance
(or not), is entirely up to LSB.

None of the above involves "rpm5.org technology" advocacy. In fact,  
rpm5.org
is attempting to become independent of issues like "LSB format" (by  
reading
multiple formats, including ar/tar/cpio/xar/deb/rpm/lsb), and LSB tag  
content
(by permitting arbitrary tags, have it your own way, and alternative  
metadata
representations).

The approach @rpm5.org is no different than the approaches at SuSE  
and RedHat.

The non-existence of a viable packaging standard is forcing alternative
software delivery solutions.

Your ISV customers will be directly affected by the changing  
implementations no
matter what.

But "LSB format" packaging is entirely LSB' to do what they wish  
with. Have fun!

73 de Jeff



More information about the lsb-discuss mailing list