How to Package Fedora RPMS Re: Prelink success story :)

[Michael Schwendt]

On Thu, 26 Feb 2004 14:13:20 -0700, Stephen Smoogen wrote:

> Here is a Spec file template with everything that should be defined in a
> way that is easily parsable by an automated
> service/QA_monkey_who_will_fling_dung_at_non_compliant_specfiles
>
> For things outside of this spec file, this is the order that we would
> like things to be in. 
> 
> Here are some good examples of SPEC files that you can use as reference
> when starting with something new.
> 
> Here are things to avoid/not do because they make QA/maintainers lives
> heck and more likely that they will throw dung at you.

This is going too far, IMHO, because it comes close to the opposite of
"common sense". ;)

For examples on spec files of packages which somehow seem to have passed
QA, simply check out existing spec files of what's in the repository
already or what has been added to it recently. For instance, a snapshot of
all spec files is linked from the main page at http://fedora.us.

The packager ought to know his own package. The packager should not
attempt at spec file beautification just to match a given template. It's
the packager who maintains the package, not the reviewer. But it would be
added value, if someone else doesn't need ages to understand the
packaging. So, e.g. comments in some places of the spec can be helpful.

Running rpmlint on the src.rpm (at least) can be helpful, but rpmlint's
output ought to be verified as rpmlint is not bullet-proof.

_From my memory, a few things that can drive a reviewer nuts:

 * A package update (with the UPDATE keyword) comes with a completely
   rewritten and reformatted spec file and even renames separate patch
   files, which makes the diff against the previous release overly
   complex. [similar thing applies to revisions during QA]

 * If a package does not even build, because it lacks obvious build
   requirements. Not everyone uses "mach", but fedora-rmdevelrpms does
   a pretty good job, too.

 * Missing %changelog comments.

 * If a src.rpm file has been adapated from some other distribution and
   the new packager appears to not have tried to understand the spec file.

 * Lots of explicit and redundant "Requires", but no or hardly any
   "Buildrequires". (both indicate the Wiki has been ignored)

 * If a packager changes his mind often and in one revision uses "rm"
   and "mkdir -p" and in another switches to %__rm and %__mkdir_p
   and vice versa.

 * Ugly and useless constructs which check whether buildroot is "/"
   prior to emptying it (and a packager who insists of leaving them in
   the spec file).

 * Upstream source location is difficult to find, URL is not in spec
   file. Source tarball has been recompressed or modified or fetched
   from some "hidden" location.

--