From The Linux Foundation
Contents |
Open Issues
This task is still poorly understood; we know we have to "uplift RPM", but how far? What do we need to add to our specification? Do we need additional tool support to augment the spec? How about other external tools, such as alien; should those be part of this task?
Vision
RPM is the standard LSB package format. Recently, it's become clear that our specification has gone stale; it's very difficult to create LSB-compliant RPMs with current tools, and our baseline reasoning for holding back (support by converter tools such as alien) is out of sync with the current capabilities of those tools.
While ISV support for deployment with packages is mixed, the community has made it clear that package management is current best practice for installing software on most Linux systems today, and thus our support for RPM must reflect that. We need to be giving ISVs reasons to deploy using packages, and not roadblocks, as we currently do.
We have two major alternatives for solving the problem:
- We could uplift the RPM specification to line up more closely with the packages being produced by RPM version 4, as shipped in the current distributions, and publish guidelines and easy-to-use recipes for creating LSB-compliant RPMs that exclude any features we decide to exclude from our uplifted spec.
- We could create a set of tools, independent from upstream RPM, which easily create RPMs which comply with the spec as shipped in LSB 3.x.
Neither alternative is exclusive of the other. In fact, if we uplift the spec, we may still need to create better tools. ISVs have told us that the process of creating a spec file and building a package, even outside of LSB compliance issues, is too difficult.
Milestones
A rough proposed schedule for this project. When we anticipate that we will reach certain milestones. Also, if the project has an absolutely-must-be-completed-by date, mention it here.
| Milestone | Plan Date | Outlook | Comments |
|---|---|---|---|
| Decide what needs to be done. | 4/11/2008 | See comments below. |
Resources
No resources have been dedicated to this project.
Hardware
No resources have been dedicated to this project.
Contacts
List of people who are working on the project and their roles.
| Name | Role |
|---|---|
| Jeff Licquia | Project Owner |
Tasks
Tasks will map many-to-one to milestones. Tasks are specific actionable work items that need to be completed in order to reach a milestone
Active
| Task | Owner | Status | Outlook |
|---|---|---|---|
| Decide on a plan of action, based on one or both of the alternatives. | Jeff Licquia | In progress | See comments below. |
Completed
| Task | Owner | Status | Outlook |
|---|
Pending
Tasks that can't be scheduled yet because they are waiting on some other task or external entity
| Task | Owner | Status | Outlook |
|---|---|---|---|
| Create a tool for bundling up binaries into packages easily. |
Comments
We have another separate page for free-form notes at LSB RPM Uplift.
Jeff Licquia 12:46, 7 March 2008 (PST)
After the conversation last Thursday in Indianapolis, there's some question if this should be a priority at all. Our strategy for LSB 4 in general seems to be focused on making the LSB more relevant to ISVs, and package issues seem to be pretty low on the prioirity list for most ISVs.
The problem is that the current spec is not usable. If we don't give it some love, at least, it will continue to be a distraction and frustrate those ISVs who follow our current recommendations and try to build a package, only to have it virtually ignored by us. Further, RPM continues to be the preferred base format for the distribution of our own tools, tests, etc. If we abandon RPM, it's arguable that it will be at least as much work revamping our own processes to use something else--never mind the work in choosing an alternative strategy for distributing our stuff.
Uplifting the current spec would probably be the least work, since the differences seem to be related to new tags allowed in RPM 4. If we don't think that ISVs will mostly care, simply making it possible to build LSB-compliant RPMs using the industry-standard toolset might be enough, at least for this round.
On the other hand, our focus this round is on providing tools to make life easier for ISVs. That would seem to argue for a tool-based approach. Ted suggested a tool that takes an install directory, package metadata, and possibly package scripts on the command line, and does all the work of building a LSB-compliant RPM without calling rpmbuild.
The question is: how many other tasks do we have? How much time can we give to this?
Jeff Licquia 09:08, 31 March 2008 (PDT)
Discussion at LSB Summit: do the tool, see if that improves uptake of RPM.
Jeff Licquia 14:44, 10 April 2008 (PDT)
There has been some opposition, and good discussion, on the lsb-discuss list; see the April archives. Some issues: possible security problem, RPM now supporting bzip2 and lzma compression.
Jeff Licquia 09:23, 21 April 2008 (PDT)