[lsb-discuss] RPM decision process
n3npq at mac.com
Thu Apr 17 07:09:17 PDT 2008
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
(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
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
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
checked in January 2008. The LSB task at the "content" level is to
whether tags are mandatory or optional, and forbidden or permitted.
At the package "usage" level -- i.e. how tags should be used by an
LSB has never attempted any working definition AFAIK. That means the
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
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
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
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
There has been no detectable LSB interest in my offers. I am
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,
is attempting to become independent of issues like "LSB format" (by
multiple formats, including ar/tar/cpio/xar/deb/rpm/lsb), and LSB tag
(by permitting arbitrary tags, have it your own way, and alternative
The approach @rpm5.org is no different than the approaches at SuSE
The non-existence of a viable packaging standard is forcing alternative
software delivery solutions.
Your ISV customers will be directly affected by the changing
But "LSB format" packaging is entirely LSB' to do what they wish
with. Have fun!
73 de Jeff
More information about the lsb-discuss