QA Checklist
Old checklist from the obsolete fedora.us project. Items should be covered by new PackageReviewGuidelines page.
This is a list of things to check for within a src.rpm during Quality Assurance testing of Fedora packages. It is to be understood as inspiration. Not everything listed here applies to every package. Not everything, which may be important, is listed here. This list is incomplete. Please add items, rewrite sections, and reorganize to complete and improve this document.
1. Does the package follow the PackageNamingGuidelines? 2. Are the sources from upstream pristine and free from trojans?
- Whenever possible verify GPG signatures, or even ask the upstream developers themselves to confirm the integrity of sources.
- Another good source is to look within SRPMS of other distributions.
3. Are the pre- and post(un)install scripts correct?
- If it installs files named *.so.* into %{_libdir} (TODO: or other directories which are listed in /etc/ld.so.conf), is there a %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig?
- If it has info files, is there a %post script that installs them, and a %postun one which removes them (and only on erase, not upgrade)?
4. Epoch
- can be optionally defined "0" or omitted entirely. Exception: Never add Epoch to Red Hat updated packages.
- Whenever you have a "Requires", "Build
Requires", "Provides", "Obsoletes", "Conflicts" or "BuildConflicts" that needs a specific version of another package, always have the epoch before the version separated with a colon. - See [1] for more info.
5. Did you check for missing build requires using ["HOWTOFindMissingBuildRequires"] ?
6. Is the Group tag an official one? See ["RPMGroups"] or /usr/share/doc/rpm-*/GROUPS.
7. Are all paths within the .spec replaced with RPMMacros ? This is particularly important when the source code accepts custom install paths via some sort of configure script.
8. If the package has a DesktopEntry, are the VFolder categories ok?
- See FedoraDesktopEntryGuidelines
- When the .spec uses desktop-file-install for to install menu entries, do not forget "Build
Requires: desktop-file-utils" - Does the desktop menu entry appear in KDE/GNOME?
9. Does the package install any unowned directories? Read the thread at http://www.fedora.us/pipermail/fedora-devel/2003-June/001458.html for details.
10. Check ownership and permissions of files and directories included within every binary RPM package, e.g. with rpm -qlv packagename. Check use of %defattr and %attr macros in %files sections.
11. The package should not use the Copyright tag. ([wiki:Self:PackagingGuidelines#tags PackagingGuidelines] )
12. Does the package ship with default passwords? Such passwords are treated as packaging-errors; see the thread at http://www.fedora.us/pipermail/fedora-devel/2003-August/001847.html for details.
13. Does the package ship daemons or similar programs which support execution as non-root? It is a packaging-error when the daemon runs as root, or as a standard user like nobody. Instead of, a special user must be used; see the discussion at http://www.fedora.us/pipermail/fedora-devel/2003-June/001492.html for details.
14. Verify that Perl modules install into vendor directories.
15. The package should invoke make as make %{?_smp_mflags} whenever possible. ([wiki:Self:PackagingGuidelines#parallelmake PackagingGuidelines] )
16. src.rpm must rebuild as non-root user.
17. The package should not use the Requires(pre,post) notation. ([wiki:Self:PackagingGuidelines#reqprepost PackagingGuidelines] )
The report to paste in bugzilla can have the format described in QAFormat
[[Category:Extras