From Fedora Project Wiki
No edit summary |
(Add category) |
||
Line 20: | Line 20: | ||
[[Category:Package Maintainers]] | [[Category:Package Maintainers]] | ||
[[Category:Packaging guidelines]] | |||
[[Category:Packaging guidelines]] | [[Category:Packaging guidelines]] | ||
[[Category:Guidelines hackfest]] | [[Category:Guidelines hackfest]] |
Revision as of 22:41, 27 February 2014
Frequently made mistakes while packaging RPMs by new packagers
There are a lot of mistakes when packaging RPMs that happen quite often. We try to collect and describe the most common ones here so you have a chance to avoid them! Feel free to add things to this list!
Especially new packagers sometimes make some mistakes that make reviewing hard and painful for both the packager and the reviewer. Avoiding those mistakes can speed up the review a lot!
- As a new to packaging, you should have already read to the Packaging/NamingGuidelines and Packaging/Guidelines . You should also be aware of ForbiddenItems .
- Use http://cvs.fedoraproject.org/viewcvs/rpms for checking SPEC file of any packages that are in Fedora.
- 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 Packaging/CommonRpmlintIssues and at ParagNemade/CommonRpmlintErrors
- 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).
- Make sure the package's build system isn't stripping binaries during its install. Otherwise you end up with an empty and useless debuginfo package. See also Packaging/Debuginfo .
- 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).