More Packaging Guidelines...

[Warren Togami]

http://www.fedora.us/wiki/QAChecklist
Some highlights from Fedora's packaging guidelines... for now the easier
points.  I'm avoiding the Epoch discussion for now since I am short on
time.

1. Are the pre- and post(un)install scripts correct?
=================================================
If it installs files named **.so.* into %{_libdir}, 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)?

2. Finding Missing BuildRequires
================================
http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires
Here is a brute force method of finding missing package BuildRequires. 
This works a lot better if you have a local apt/yum repository, or cache
everything.

Any suggestions for a cleaner way of testing for missing BuildRequires?

Any suggestions for the "list of packages that should not be in
BuildRequires" because they occur too frequently and should be in a
standard build environment?

We should define a standard minimal build environment for RHLP.  Fedora
currently does so implicitly with the dependencies of
fedora-rpmdevtools.

3. Finding Redundant BuildRequires
==================================
http://www.fedora.us/wiki/HOWTOUseRequires
How not to be overzealous in adding BuildRequires, and including
versioned dependencies when not needed.  This document needs to be
clarified a bit but otherwise good.

4. RPM Macros
=============
http://www.fedora.us/wiki/RPMMacros
Whenever possible use directory macros rather than hard coded
directories.  RHLP's docs should probably state the "why" too.

5. Strict Directory Ownership
=============================
Any directory created by the package should be owned with a %dir entry
within %files.  rpm -vv shows unowned directories during installation,
and I believe Enrico wrote a tool to test many RPMS and look for unowned
directories.

Attacking Epoch when I have more time later this week...

Warren Togami
warren at togami.com