[lsb-discuss] RPM decision process
tytso at mit.edu
Thu Apr 17 08:36:23 PDT 2008
On Thu, Apr 17, 2008 at 10:09:17AM -0400, Jeff Johnson wrote:
> 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.
Thanks for the confirmation. It was Russ who repeatedly claimed that
the lead had changed in the RPMv4 format, and that we were busted
because we hadn't made those changes because of dire cryptographic
problems. I remember that there were problems, but I thought it was in
the interpretation of the tags.
> 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.
Yes, and what the tags are, and what they mean, have not been defined
in any systematic or precise way past RPMv4. Neither has there been
any documentation about what various RPM implementations will do
differently if the value in the minor and major version numbers
I will note that the web page here:
Implies that at least some implementations set major version number 3,
minor version 1, as well as major version 4, minor 0. What that does
is not specified.
It was Russ on the call who made rather energetic assertions that if
we didn't uplift our package specification to the RPMv4 format, that
we might as well go back to compressed tarballs, and he also made the
further suggestion that you also felt quite strongly about that.
Thank you for confirming that in fact there is no real difference at
least as far as the RPM header/lead is concerned. This is in rather
direct contradiction to what Russ asserted on Wedensday on the LSB
> 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.
There are definitions in the LSB specification. I will agree that
they are rather loose. In particular, one of the things which is not
specified is what arguments are passed to the install/remove
scriptlets in the case of fresh install versus upgrades. If you would
> like to contribute better text, it would be gratefully accepted.
> 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.
Yes, we do have an open bug that the sort order for version numbers is
not specified; again, authoratative text would be gratefully accepted.
You could either paste it into the bugzilla entry here:
Or send the text or a URL to the list, and someone will enter it into
the BZ for you.
> 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.
It may be that I misunderstood some of what Russ said. Russ was
rather *passionate* on the call, and as I said earlier, he was the one
who claimed your position was "RPMv4 package format, or go back to
using tarballs". That I think he was rather clear upon. And at least
once or twice, I thought he made various assertions that if we didn't
take up some of the enhancements that you were planning in the RPM5
series, that we would be fatally harming the ISV's, and so it didn't
matter that both Red Hat and SuSE weren't planning on using RPM5; we
should specify such format changes in the LSB. I am very glad to hear
that "this is simply not the case", and I am quite happy to chalk it
up to my not understanding his (and yours) position properly.
73 de N1ZSU,
More information about the lsb-discuss