[lsb-discuss] RPM decision process

[Jeff Licquia]

So, administrivia aside, the substantive reply.  But first:

I'm going to ride herd on this thread when it comes to respect.  We can 
disagree without making comments about "amateurs" and "misguided" and so on.

In particular, this idea that somehow these decisions are the result of 
anti-inclusiveness or collusion or some such are really offensive.  I 
wouldn't have called this conversation to the list if I wasn't really 
interested in your input.

Mis-communication happens.  You can treat it as evidence of malice, or 
just a mistake.  If you choose the former, good luck to you.  If you 
choose the latter, then the fix is to communicate; let's do that, OK?

R P Herrold wrote:
> My opening remark to the comment that 'We agreed at the face- 
> to-face that RPM package version format uplift was not 
> important and might be deferred' was -- Either uplift to RPM 
> package version 4, or just use tarballs [ar, cpio, XML blobs, 
> whatever];  RPM package version 3 is long obsolete, 
> incompletely protects the content, and is subject to a known 
> modification attack which cannot be detected in the way the v 
> 3 signing leade is used.

That (the modification attack) sounds like something that should be 
addressed.

> JBJ noted:
> 
> No matter what, all this stoopid configgery to produce a LSB 
> "standard" package could be simplified to a --lsb option in 
> rpm if anyone cared to ask me to implement.
> 
> No one has.
> 
> But I do ask the question:
>       What use is rpm as a LSB "standard" format if everything 
> in rpmbuild needs disabling?
>       Isn't cpio or tar or ... a better choice than a 
> lobotomized rpmbuild?
> 
> -------- JBJ quote ends

Way back when, I kept saying that Debian packages were superior to RPMs, 
and now I have my confirmation. :-)

I joke, but really, the evidence suggests that RPM was, in fact, very 
useful even in its version 3 configuration.  I remember switching from 
Slackware to Red Hat 3 way back when precisely because of the advantages 
of RPM.

Given that usefulness, I don't see why the better must be the enemy of 
the good.

> I had upstreamed the LSB RPMBUILD variant's errors at:
>     http://bugs.linuxbase.org/show_bug.cgi?id=1875
> which remains open.

In our bug evaluation, we didn't get to 1875, but I see from Ted's 
spreadsheet that the bug got an average rating of 2.2 on a 5-point scale 
(lower numbers being higher priority).  That would probably put the bug 
on the same priority as the uplift, as things stand now.

That would suggest that, should the uplift take higher priority, the bug 
should probably rise with it.

> The RPM package version 4 has been documented for years -- at 
> least since 2004 in Max RPM on-line:
>      http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html
> in the revision to Ed Bailey's initial Maximum RPM, done, as I 
> recall, by Paul Nasrat when Paul was then employed at Red Hat 
> (and not the dreaded JBJ ;)  ]

OK.  BTW, I've added some links here:

https://www.linux-foundation.org/en/LSB_RPM_Uplift

All are welcome to expand on those, add further information, etc.

> Ted's complaint about dependency specification inter ** 
> distribution ** is uninteresting, irrelevant and misguided; 
> the issue is what can an ISV reply upon when installing to an 
> LSB conformant distribution, exposing LSB managed names; and 
> the answer is LSB exposed 'Provides', administered in the 
> LANANA or in the spec document itself.

I don't think this is exactly what Ted was talking about, but OK.  The 
positive plan is sensible.

> Stuart Anderson took a swing at that ** distribution ** 
> level issue:
>      http://bugs.linuxbase.org/show_bug.cgi?id=967
> Still open

I note that not a single distro has weighed in on that bug.

That's probably why the fix hasn't been pushed: we don't have the 
authority to make calls like that.

> Similarly, anonymous ISV's complaints of:  1: too hard, and 2: 
> not our build system and we support big iron Unix, are cited 
> by him and others as why 'yet another package builder' needs 
> to be written [int: it's already done -- see the JBJ post set 
> out infra], contra my express identification of two major ISV, 
> actively ** using ** RPM %pre and %posts [beyond the LSB 
> minimum required implementation].

Well, we're always happy to take code that's already done.  OTOH, I 
don't know that we're in a position to take all of RPM 5 into the SDK, 
so the tool's deps on RPM 5 will have to be looked at.

> 1. 'Too hard' is just sloth, pure and simple.

Maybe they're all lazy bums.  Is telling them so going to get us 
anywhere?  We have to deal with the world we live in, and not the world 
we want.

Sometimes giving people what they want--while, at the same time, 
encouraging them down a certain path--gets you farther.  That's what 
we're trying to do.

(Link added to your tools on the above wiki page.)

> I _know_ how much history and hard 'dark corners' remain in 
> rpm package building.  Red Hat has gone through two succesors 
> to JBJ re-learning the lesson.  I found it again confirmed 
> doing task decomposition for Alien earlier this year, as I 
> blocked out the work there.  Dumbing down the RPM package 
> format to present a simplified form for the current Alien; 
> 'smartening' 'alien' to understand excised elements is to have 
> to recap a decade's work since RPM was done in perl. 
> Extending then to the later package format is more, but not 
> that much more.

Sure.  But it's still got to be done, unless you know of a good way to 
access those lessons from alien without having to rewrite them.

> While composing this, I happened to get a call from a huge 
> customer of a LSB certified Enterprise distributor's product, 
> and asked: 'How important is LSB certification on your 
> purchasing bullet list for products.' Sadly the answer for 
> them is:  Commercial SLAs and support matter; the LSB 
> certification is not even on their radar.

Well, sure.  That was, in fact, a large part of the conversation we had 
at the Summit, and has been a theme of many of our conversations with 
lots of ISVs.

It is, in fact, a motivator for a lot of what we want to do in LSB 4.

> I am not sorry for speaking frankly -- Please: do RPM right, 
> or stop doing it; to the extent that the conference call 
> bridge lags resulted in 'talking over one another' and made 
> for poor communication, I trust those on the call understand.

Frank talk is welcome; disrespect is not.

We took this off the call precisely because, with the strong opinions 
represented and the time allowed, we weren't going to do anything 
productive about it then.  I hope we can do something productive about 
it now, in an environment where we can be a little more cool-headed and 
explain ourselves well.