From Fedora Project Wiki
No edit summary |
(Fix package source url) |
||
| (10 intermediate revisions by 5 users not shown) | |||
| Line 5: | Line 5: | ||
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! | 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 [ | * 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 | * Use https://src.fedoraproject.org/ 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 [ | * 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 [[Common_Rpmlint_issues]] and at [[ParagNemade/CommonRpmlintErrors]] | ||
* Run the fedora-review tool and point it at the package review request bugzilla ticket. It downloads the latest src.rpm and spec file from the "SRPM URL:" and "Spec URL:" lines you've posted and performs many helpful checks on your package. | |||
* 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. | * 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. | ||
| Line 19: | Line 21: | ||
* 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). | * 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). | ||
[[Category:Package Maintainers]] | |||
[[Category:Guidelines hackfest]] | |||
Latest revision as of 20:30, 12 March 2021
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 https://src.fedoraproject.org/ 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 Common_Rpmlint_issues and at ParagNemade/CommonRpmlintErrors
- Run the fedora-review tool and point it at the package review request bugzilla ticket. It downloads the latest src.rpm and spec file from the "SRPM URL:" and "Spec URL:" lines you've posted and performs many helpful checks on your package.
- 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).