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.

Dependencies

Contingency Plan

As soon as the technical problems have been fixed moving more sub packages to noarch can be a continuing process.

Documentation

What's this all about?

With version 4.6.0 RPM supports subpackages being noarch by just
adding "BuildArch: noarch" to their subpackage section in the spec
file.

The noarch subpackages built on the different arches are going to be
compared by koji with rpmdiff ignoring time stamp, size and md5 sums of
files. If any other differences are found the build will be rejected.
Even with those automatic checks in place it is the
responsibility of the packager to make sure that the package is really
arch independent - as for regular noarch packages, too.

Candidates for being switched to noarch

To get a list with good candidates all x86_64 packages that contain no binaries/libs (as known to rpm) and no files
in /lib64 or /usr/lib64 were selected as a starting point. To further refine the selection and get an idea what can go wrong
rpmdiff was run against the i386 sister packages - both with the relaxed koji and the strict -t settings. This showed a small number of false positives - mostly
development packages that put files in different locations or undetected binary packages. Subpackages are marked by one surrounding '*' if they only fail the more strict rpmdiff -t check and by two if they also fail the rpmdiff check as used by koji. It is assumed that packages without '*' can be directly switched to noarch (assuming they don't do weird stuff on other arches). One '*' will require a more detailed look but should be OK in most cases and two '*'s is most likely a sign for a false positive. The diffs can be found below in a full and a hand shortened version.

To be able to detect arch independent files in (/usr)/lib x86_64 packages have been examined. It is assumed that lib32 and noarch files can be moved to noarch sub packes, bin64 and lib64 can't and bin32 should not be found. This is only a very rough estimate and must be checked for each packages and doesn't take other architectures into account. Nevertheless it gives a good idea of what packages should be considered and what results can be expected.

Note that it is probably not worth splitting all possible or even just the 1000 packages above. But the first few dozen have a very strong impact.

For some packages it might be better to just change the borders among the subpackages instead of blindly splitting them. Such situations are not reflected well in the above lists.

What about other packages?

A lot of other packages could also make use of this feature. When
considering to split up your package please avoid too complicated spec
files. We still have to develop packaging strategies to be applied
throughout the distribution and it doesn't look like this is going to
happen in the F11 time frame.

What can you do as a packager?

There are still fixes for koji that must hit the
Fedora build system first. So noarch subpackages DO NOT WORK within Fedora
yet. We hope that this can be solved soon.

If you are interested you can already play with noarch subpackages by
building with mock and comparing the results on different arches with
the koji version of rpmdiff (files differing in S, 5 and T might be ok). There is going to be
little time between support in koji and the
feature freeze. So being prepared for this short time slot is a good
thing.

Please add the packages you changed or plan to change to /PackagesChanged.
Put the later in parenthesis. Thanks!

What if you don't want to change your packages?

That's perfectly fine. There is no plan to force packager to use
noarch subpackages. I hope we can develop a more detailed plan on how to
make use of this feature in future Fedora releases. You might be
interested in taking part in this discussion.

What does that mean for the Packaging Policy?

The packaging policy will require a few additions. See /PolicyChanges.
Any comments and help is welcome.

Release Notes

Not applicable as visibility for the users is low and developers need to know before the release.