[lsb-discuss] Fwd: RPM decision process

[Jeff Johnson]

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  
>>> 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.
>>
>
> RUss said the format was documented in "Maximum RPM". That is true.
>
> Meanwhile, the lead version is ettable through a macro for like 5  
> years.
> 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
>> changes.
>>
>
> Not true. The LSB packaging document has changed several times to  
> include
> 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  
> are
> 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:
>>
>> 	http://wiki.rpm.org/FileFormat
>>
>> 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
>> call.
>>
>
> 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  
> definitely
> having trouble understanding what I am saying (as I've pointed out  
> above),
> 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  
>> 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:
>>
>> 	http://bugs.linuxbase.org/show_bug.cgi?id=1462
>>
>> 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  
>> 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.
>>
>
> 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...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080417/92a9987f/attachment.htm