The Linux Foundation is a non-profit consortium dedicated to fostering the growth of Linux.
|
|
LSB:PM:LSB RPM Uplift
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. - DONE (Stew)
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
Possible Tasks
| Task | Owner | Status | Outlook | Reference |
|---|---|---|---|---|
| Correct and clarify several existing spec entries for RPM* values | TBD | not started | bug 1554 | |
| Specify versioning and EPOCH | TBD | not started | bug 1462 | |
| Add additional RPM index tags to the spec and pkgchk | TBD | not started | bug 1875 | |
| Clarify/update spec for package naming issues | TBD | not started | bug 147 | |
| Make a decision and possibly update the spec with regards to requiring ISVs to name packages lsb-LANANA* | TBD | not started | bug 77 | |
| Typo of "description" in packaging spec | TBD | not started | lsb discuss #1 | |
| Need to distinguish between RPMTAG_DISTURL and RPMTAG_URL | TBD | not started | lsb discuss #2 | |
| Need improved description of RPMTAG_RPMVERSION | TBD | not started | lsb discuss #3 | |
| Specify what is meant by locales in RPMTAG_HEADERI18NTABLE description | TBD | not started | lsb discuss #4 | |
| RPMTAG_HEADERIMMUTABLE should not be included for current LSB format, only RPMV4 | TBD | not started | lsb discuss #5 | |
| method for encoding RPMTAG_SUMMARY, RPMTAG_GROUP not specified | TBD | not started | lsb discuss #6 | |
| The RPMTAG_SIZE tag also includes 4096 bytes for each directory included in a payload | TBD | not started | lsb discuss #7 | |
| definition of RPMTAG_PACKAGER incorrect | TBD | not started | lsb discuss #8 | |
| Should specify RPMTAG_FILENAMES, not RPMTAG_OLDFILENAMES, and some question whether this should be "Optional" or not | TBD | not started | lsb discuss #9 | |
| RPMFILE_EXCLUDE (and RPMFILE_README/RPMFILE_LICENSE) should not be specified | TBD | not started | lsb discuss #10 |
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 |
|---|---|---|---|
| Create a tool for bundling up binaries into packages easily. | Stew Benedict | We have a published implementation now (lsb-makelsbpkg) | May need continued maintenance as it get's wider usage and feedback. May need to revamped slightly for RPMV4 if we uplift. |
Pending
Tasks that can't be scheduled yet because they are waiting on some other task or external entity
| Task | Owner | Status | Outlook |
|---|
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)