[lsb-discuss] RPM decision process
jeff at licquia.org
Wed Apr 16 10:09:29 PDT 2008
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
More information about the lsb-discuss