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. --
