m (→Current status: new update date) |
|||
Line 9: | Line 9: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/11|Fedora 11]] | * Targeted release: [[Releases/11|Fedora 11]] | ||
* Last updated: --[[User:Ffesti|Ffesti]] | * Last updated: --[[User:Ffesti|Ffesti]] 19:17, 29 January 2009 (UTC) | ||
* Percentage of completion: 25% | * Percentage of completion: 25% | ||
Revision as of 19:17, 29 January 2009
Support Noarch Sub Packages in Fedora
Summary
Since some months RPM supports sub packages being noarch. Right now the Fedora infrastructure does not support this feature. This feature will provide the technical abilities to use noarch sub packages and also provide help to use them within packages all over the distribution.
Owner
Current status
- Targeted release: Fedora 11
- Last updated: --Ffesti 19:17, 29 January 2009 (UTC)
- Percentage of completion: 25%
Detailed Description
There are several steps needed:
- Support in rpm (100%)
- Support in koji (25%)
- Support in other parts of the infrastructure (unknown)
- Support in test/verification tools (unknown)
- rpmlint (?)
- ... (?)
- Get a list of possible candidates (sub packages) (90%)
- Write a mail to f-d-l and package owners (0%)
- Write best practise documentation (0%)
- Get packaging policy adjusted (see /PolicyChanges) (0%)
- Get the packages changed
Benefit to Fedora
Noarch packages have several benefits over arch dependent packages:
- They can be shared between different architectures and thus use up less disk space and bandwidth on both the Fedora infrastructure and our mirrors
- They avoid double installation of data for multilib packages.
- They tell the user that the content of the package is arch independent.
By increasing the use of noarch packages we also increase the effect of these benefits.
Additionally we can get rid of some hacks that are used to generate noarch sub packages for very few packages right now.
Scope
A small statistic on Fedora rawhide x86_64 (2009-01-22) to give an idea how many packages/files/bytes could be affected:
The files are split into 3 groups:
- binary: files rpm knows that they are arch dependent
- libdir: files that are not binaries but reside in (/usr)/lib(64)
- noarch: everything else
Libdir files should be noarch in most cases. Sizes are (uncompressed) bytes in files and though do not directly map to the size of packages nor to used disk space.
15204 packages (44 GB in 2.0 M files, 100%) 41 k binary files (8.8 GB, ~20%) 298 k libdir files (7.1 GB, ~16%) 1.7 M noarch files (28 GB, ~64%) 8762 x86_64 packages (25 GB in 1.0 M files, 100%) 31 k binary files (6.7 GB, ~27%) 182 k libdir files (5.9 GB, ~24%) 826 k noarch files (12 GB, ~48%) 3132 i386 packages (5.3 GB in 280 k files, 100%) 10 k binary files (2.0 GB, ~38%) 32 k libdir files (551 MB, ~11%) 237 k noarch files (2.7 GB, ~51%) 3308 noarch packages (13 GB in 755 k files, 100%) 88 binary files (2.3 MB, ~0.2%) 84 k libdir files (635 MB, ~5%) 671 k noarch files (12 GB, 95%)
903 (sub) packages in 571 source packages could be directly switched to noarch (filtering out 32 bit packages): media:NoarchCandidates.txt. These are all x86_64 packages that do neither contain binary files (as known to rpm) nor files in (/usr)/lib64/.
Test Plan
- Create one noarch subpackage by adding BuildArch: noarch to the subpackage section
- Scratch build the package to see whether there are any problems with koji
- Build package for rawhide - check that it correctly shows up in the repository and is shown as noarch package in the metadata
- See if the package installs correctly via yum
- Check if updating from a arch dependent previous version to the new noarch package works
User Experience
- Slightly improved mirrors due to less transfer size
- Only packages containing binaries will be arch dependent
Dependencies
- No dependencies except the steps listed in the #Detailed Description.
Contingency Plan
- Move target to Fedora 12
- As soon as the technical problems have been fixed moving more sub packages to noarch can be a continuing process.
Documentation
- Incomplete: Documentation will be created as part of this Feature (see #Detailed Description).
Release Notes
Not applicable as visibility for the users is low and developers need to know before the release.