Packaging tricks

This page is used to hold packaging related informations that should not be in guidelines (because they are controversial, or because we don't want to inflate the guidelines even more). The guidelines are at PackageMaintainers/MainPagePackaging. A page for common rpmlint issues carries similar recommendations PackageMaintainers/CommonRpmlintIssues.

Recommendations for review requests

• Use http://cvs.fedoraproject.org/viewcvs/rpms for checking SPEC file of any packages that are in Fedora. Having a look at other packages can give very interesting insights. However, it should always be remembered that some packages may not be in sync with the current guidelines (and some packages are under review).

• Run rpmlint on both the SRPM and the binary RPMs before uploading them for review. Look at the output closely and fix those things that need fixing. (Run "rpmlint -i" for additional explanatory information about each issue.) If there are errors where you are unsure if they need fixing mention them in the bugreport and ask for advice. If there are known false-positives mention them, too. Some additional information about common rpmlint errors and how to deal with them is at PackageMaintainers/CommonRpmlintIssues.

• Increase the "Release" tag every time you upload a new package to avoid confusion. The reviewer and other interested parties probably still have older versions of your SRPM lying around to check what has changed between the old and new packages; those get confused when the revision didn't change.

• One Review-Bug for one package. Reviewing and tracking multiple packages in one bug is painful. If the packages depend on each other let the bugs block each other (See the fields "Bug ??? depends on:" and "Bug ??? blocks" in bugzilla).

• List your binary rpms in verbose mode (rpm -qplv filename.rpm) and verify that the included files and directories and their file access permissions are correct. During review there are still too many packages, which install files into a new directory, but don't include the directory itself, or which install files with wrong access permissions (like executable documentation or non-executable shared libraries).

Recommendations for a sane review process

• Let everybody comment on the review.

• Comments on items that are not blockers in the guidelines are relevant. The goal of the review is to have good packages, the guidelines are not bureaucratic formal rules, but best packaging practices (and conventions), still they cannot and should not cover everything.

• Exceptions from guidelines may happen. In that case it may be a good idea to have somebody ask on the relevant lists for help/advice, especially if there is disagreement.

• Answer questions from all the comments, even those that are not blockers.

• Even if the review has been accepted, let some time for others to comment if the review was fast.

• Comments that are to be fixed upstream may be relevant in a review request. Don't hesitate to communicate with upstream during the review if an issue that is relevant for upstream has been found out. It may happen that a packages not in shape for inclusion in fedora and requires some work upstream before being imported.

Application binary interface changes (controversial)

Application binary interface (ABI) changes in libraries (with a change in soname) should be avoided in fedora releases and done only in rawhide, except when solving a security issue or a very grave bug.

When breaking ABI, it is nice to warn on the fedora-devel-list and especially the package maintainers who depend on your package ABI. Dependent packages may be found using:

 repoquery --arch=src --whatrequires mypackage-devel 

Some interesting utilities exist for finding differences in ABI, and finding which package provide sonames, rpmsoname and rpmsodiff.

Acceptable use of rpath (recommendation)

Using rpath for libraries in system library directories is forbiddeen in fedora. It may be acceptable, and even desirable to use rpath for internal libraries that are nevertheless installed (for example to factor out code for different executables). That way it could be avoided to have these libraries installed on system paths. For example the libraries could be installed in:

 %{_libdir}/myapp/libmyapp.so.0.3.4 

And have the rpath set to %{_libdir}/myapp/.

Install dlopened objects out of %{_libdir} (controversial)

Objects that are dlopened and not linked against should not be in %{_libdir}, but in a directory below libdir where the application dlopening the object should search for. This is already the setup used by most packages, for example, there is typically a specific directory for plugins containing the dlopened objects.

Use of common namespace

Package files and directory are installed in places where name conflicts are possible. Therefore the file names should be specific of the package. This means avoiding short names (less that 3 or 4 letters), or names that are too generic (like compiler, viewer, show, convert...). There are some packages that already do that, for some it is not an issue since they are covered by a standard (like POSIX utilities cat, ls). Those issues are better tackled with upstream, but using prefix or postfix can also be used in fedora.

Avoiding using fedora or redhat in a visible manner in spec files

It is better to avoid using the words fedora or redhat in spec files, to help others wanting to reuse the spec files (be it only in EPEL). dist or distribution can be used instead. For example README.fedora could be called README.dist instead. Of course this doesn't cover internal details like spec file conditionals like %fedora or %rhel.