From Fedora Project Wiki
< Changes
mNo edit summary |
|||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 9: | Line 9: | ||
* Name: [[User:ffesti| Florian Festi]], [[User:pmatilai| Panu Matilainen]] | * Name: [[User:ffesti| Florian Festi]], [[User:pmatilai| Panu Matilainen]] | ||
* Email: rpm-maint@rpm.org | * Email: rpm-maint@rpm.org | ||
* Release notes owner: | * Release notes owner: [[User:Pbokoc| Petr Bokoc]] pbokoc at redhat dot com | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
| Line 20: | Line 20: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/21 | Fedora 21 ]] with follow ups in the next release(s) | * Targeted release: [[Releases/21 | Fedora 21 ]] with follow ups in the next release(s) | ||
* Last updated: 2014/ | * Last updated: 2014/06/30 | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
Bugzilla states meaning as usual: | Bugzilla states meaning as usual: | ||
| Line 29: | Line 29: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1086274 #1086274] | ||
== Detailed Description == | == Detailed Description == | ||
| Line 54: | Line 54: | ||
* Proposal owners: The RPM code base needs to get stabilized and release ready. The release candidates need to be tested in rawhide. | * Proposal owners: The RPM code base needs to get stabilized and release ready. The release candidates need to be tested in rawhide. | ||
* Other developers: Will test the release candidates during normal operation in raw hide. Need to report issues and bugs. | * Other developers: Will test the release candidates during normal operation in raw hide. Need to report issues and bugs. | ||
* Release engineering: | * Release engineering: Have a look for compatibility issues. | ||
* Policies and guidelines: Packaging policies might need reconsidering in the light of the new options (F22 or even F23 time frame). | * Policies and guidelines: Packaging policies might need reconsidering in the light of the new options (F22 or even F23 time frame). | ||
| Line 70: | Line 70: | ||
* Packagers will be able to use weak dependencies | * Packagers will be able to use weak dependencies | ||
* API users will be able to access file data more cleanly and access payload data for the first time | * API users will be able to access file data more cleanly and access payload data for the first time | ||
* A new tool rpm2archive | * A new tool rpm2archive will allow converting rpm packages to tar files instead of the outdated cpio format | ||
** The new tool will work with files >4GB while cpio (and though rpm2cpio) does not | ** The new tool will work with files >4GB while cpio (and though rpm2cpio) does not | ||
| Line 82: | Line 82: | ||
== Contingency Plan == | == Contingency Plan == | ||
Go back to rpm-4.11. It is unlikely that this requires reverting some changes in other packages as the new features will probably not already be used in F21. | * Contingency mechanism: Go back to rpm-4.11. It is unlikely that this requires reverting some changes in other packages as the new features will probably not already be used in F21. In case something really bad happens it might be necessary to rebuild all packages built with the broken version - although there are no new features that suggest such thing being likely. | ||
* Contingency deadline: Alpha Release | |||
In case something really bad happens it might be necessary to rebuild all packages built with the broken version - although there are no new features that suggest such thing being likely. | * Blocks release? Yes | ||
* Blocks product? - | |||
== Documentation == | == Documentation == | ||
| Line 90: | Line 91: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Release notes: http://rpm.org/wiki/Releases/4.12.0 | |||
== Release Notes == | == Release Notes == | ||
| Line 99: | Line 100: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF21]] | ||
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> | <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> | ||
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--> | <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--> | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
Latest revision as of 18:37, 14 August 2014
RPM-4.12
Summary
Update RPM to the upcoming 4.12 release.
Owner
- Name: Florian Festi, Panu Matilainen
- Email: rpm-maint@rpm.org
- Release notes owner: Petr Bokoc pbokoc at redhat dot com
Current status
- Targeted release: Fedora 21 with follow ups in the next release(s)
- Last updated: 2014/06/30
- Tracker bug: #1086274
Detailed Description
The current upstream repository contains several improvements that need to get released and integrated into Fedora:
- Support for weak dependencies
- Support for packaging files > 4GB
- Support for real package reinstallation
- New API for accessing files and file contents
- New tool for converting rpm packages to tar files
- Internal plugin interface
- Massive code clean ups
- Many bug fixes
Some of these features require the new version to reach the builders. So actually introducing them in Fedora will take longer that the Fedora 21 release. Nevertheless updating RPM in F21 is the first step to make this happen.
Benefit to Fedora
The above plus closing the gap between RPM upstream and the Fedora version.
Scope
- Proposal owners: The RPM code base needs to get stabilized and release ready. The release candidates need to be tested in rawhide.
- Other developers: Will test the release candidates during normal operation in raw hide. Need to report issues and bugs.
- Release engineering: Have a look for compatibility issues.
- Policies and guidelines: Packaging policies might need reconsidering in the light of the new options (F22 or even F23 time frame).
Upgrade/compatibility impact
Using some of the new feature will break forward compatibility. Packages using these features will not be able be build or be installed on older Fedora versions. Backward compatibility is expected to be maintained.
How To Test
Testing is done in full operation.
User Experience
- Packagers will be able to package files >4GB
- Packagers will be able to use weak dependencies
- API users will be able to access file data more cleanly and access payload data for the first time
- A new tool rpm2archive will allow converting rpm packages to tar files instead of the outdated cpio format
- The new tool will work with files >4GB while cpio (and though rpm2cpio) does not
Dependencies
- >4GB support and weak dependencies require the builders to be updated to rpm-4.12, too.
- Weak dependencies need to be supported by create_repo, and the updaters (and may be the packaging policy) to be useful
- >4GB support requires the infrastructure to support those file sizes to be usable.
These dependencies do not actually block updating RPM.
Contingency Plan
- Contingency mechanism: Go back to rpm-4.11. It is unlikely that this requires reverting some changes in other packages as the new features will probably not already be used in F21. In case something really bad happens it might be necessary to rebuild all packages built with the broken version - although there are no new features that suggest such thing being likely.
- Contingency deadline: Alpha Release
- Blocks release? Yes
- Blocks product? -
Documentation
Release notes: http://rpm.org/wiki/Releases/4.12.0