[lsb-discuss] RPM decision process

[Jeff Licquia]

After the rather interesting discussion that happened on the call, I 
thought it might be useful to set out the case for the plan we adopted 
at the LF Summit in detail.

To sum up, the plan from the Summit was to make the RPM uplift a lower 
priority, and to write a new build tool for easily building simple RPMs. 
  There was strong disagreement with this plan on the call; see the 
notes for more details.

The problem we have is that LSB RPM uptake is pretty much nonexistent. 
When we ask ISVs about doing RPMs, we tend to get a few common answers:

  - RPMs demand too much.  Some don't want to hassle with spec files. 
Some have a build process already, and don't want to re-engineer the 
whole thing to give RPM control over the build.  Some give up on making 
the RPMs comply with our spec because it's too old.

  - Cross-platform ISVs want a common installation system across all 
archs to support, and don't use native packages on any platform.

  - Those ISVs that build RPMs use the latest features, build one 
package per distro, and often build Debian packages as well.  For these, 
a useful common profile might reduce their workload, but they have 
already put in the effort to understand packaging well.

The only places where our spec provides pain to ISVs is that rpmbuild 
can't be made to build them easily.  No ISV has told us that they would 
do RPMs, except that they need some RPMv4 feature, and that the spec is 
useless to them until they get it.

If no one uses the LSB profile, it might just need to be deprecated. 
(That was pointed out on the call.)  But there's evidence that, if LSB 
RPM were more useful and easier to get working, there would be more uptake.

Our plan is designed to answer this question.  By removing the barriers 
we're hearing that ISVs actually have to adopting RPM, we hope that 
increased use will bring increased demand for the newer features in RPM. 
  If it doesn't, maybe that's telling us something.

We do expect that people will outgrow the simple build tool, and our 
answer will be to point them to rpmbuild.  It would probably be a good 
idea if our tool made that easy.  For LSB 4, it could maybe 
auto-generate a spec file which worked around the problems in our old 
specification, if we don't get to the uplift in time.

Which is a good point, too.  "Low priority" doesn't mean "we don't need 
to do it".  It just means that we have finite resources and can't do 
everything worthwhile.  If a team presented us with an uplifted spec and 
tools, we wouldn't turn it down.

Ultimately, though, we have to make tough choices, and this may be one 
of them.