[lsb-discuss] Fwd: RPM decision process
n3npq at mac.com
Thu Apr 17 10:05:27 PDT 2008
Pardon the bifocals, I invariably get tripped up on Reply-to-all policy
mailing lists. Another forward follows ...
Begin forwarded message:
> From: Jeff Johnson <n3npq at mac.com>
> Date: April 17, 2008 12:57:42 PM EDT
> To: Theodore Tso <tytso at mit.edu>
> Subject: Re: [lsb-discuss] RPM decision process
> On Apr 17, 2008, at 11:36 AM, Theodore Tso wrote:
>> 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
>>> value in byte 5 of the rpmlead, is exactly the same as the RPMv4
>>> 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.
> RUss said the format was documented in "Maximum RPM". That is true.
> Meanwhile, the lead version is ettable through a macro for like 5
> You can arrange for whatever number you wish to appear in byte 5.
> "Whatever number you wish" includes the specific values "3" and "4".
>>> The content (i.e. the tags) have changed. The most signif
>>> 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
> Not true. The LSB packaging document has changed several times to
> additional tags. That is also true for the confirmance checking tools.
> Whether the tools agree with the document is a LSB consistency issue.
> I know of several discrepancies between the tools and the document.
> Honking about RPM4 not being documented misses the point.
> The LSB packaging standard has not been updated to include additional
> tags (I have offered yearly to Mats and Stuart, usually at OLS).
> LSB's role is to define a :SB packaging spec. Enumerating tags that
> permitted (or forbidden), mandatory or optional, is a LSB, not an
> RPM, task.
> I've offered to help (and have helped) define that information over
> many years.
>> 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.
> Surely -- since you were the main voice advocating reverting from "4"
> to "3" -- you recall the issues.
> What is implied by a version change is that the version changes. What
> that means can only be resolved by reading addiotional documentation.
> LSB has failed to maintain or provide adequate documentation on
> what LSB has chosen as its standard format.
> This has little to do with RPM documentation. RPM changes in order
> to provide "features" etc. None of the changes have not been described
> at the time the changes were made.
>> 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
> Just in case: I said that the "format" has not changed. I did not
> say that there was "no real difference".
> In fact, I tried to say exactly the opposite: there are two divergent
> formats because Red Hat and SuSE have chosen different means
> to provide multilib product through rpm packaging.
> My apologies if you misunderstand what I attempted to say. Pehaps
> I should explitly underline what I attempted to say:
> The are very real differences in rpm packaging distributed by
> Red Hat and Suse.
> And neither format used widely in commercial linux
> distributions is "LSB format".
> Otherewise take up your issues with Russ directly. You are most
> having trouble understanding what I am saying (as I've pointed out
> and I would p[refer not having you putting words into my mouth.
>>> 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
>>> 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
>> 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.
> I believe it was my suggestion on the LSB packaging list that
> may have led to that bug. I do know that I suggested that
> "version" is inadequately defined in LSB packaging standard,
> and I dimly remember a confirmation from Mats agreeing.
> I'm not sure what you mean by "authoritative" in a LSB standard
> context. rpmvercmp.c is certainly well known and widely used
> for a decade. Which defacto defines what all rpm versions
> that LSB is targeting quite adequately. Meanwhile, a "standard"
> version for packages, not rpm packages, is what needs to
> be attempted. Jason Gunthorpe documented several differences
> between dpkg and rpm version comparison years ago.
> I have revisited the problem space, and have published differences
> between dpkg <-> rpm versioning as well as suggesting privately that
> a common version comparison might be achievable and
> would help end linux packaging wars.
> Any remaining issue is up to LSB, not me.
> Or perhaps I misiunderstand your request for "authoritative"?
> AFAIK the authority for LSB packaging is LSB, not otherwise.
>>> 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
>> who claimed your position was "RPMv4 package format, or go back to
>> using tarballs". That I think he was rather clear upon. And at
>> 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
>> 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.
> If you are happy with "may be", so am I. Other opinions are possible.
> Meanwhile, I don't believe that any purpose is served by continuing
> with the existing "LSB format" packaging standard. That's just my
> opinion, I encourage you to go out and identify and document what
> rpm packages are currently widely deployed.
> With the exception of Sun java packaging, and the occaisional
> IBM hiccup, there are no "LSB format" packages around anymore.
> But by all means, don't take my word: Go look.
>> 73 de N1ZSU,
> So where does "Free for Amateur Radio Use" licensing fit into LSB?
> I have nearly adopted that licensing for rpm5.org development
> purposes on several occaisions, and may still license my development
> efforts that way.
> Hams are at least friendly and polite with no advocacy agenda.
> 73 de Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lsb-discuss