RPM building section of RHL's developer guide

[Matthias Saou]

Hi,

I've got a few minor remarks regarding the example spec file given here:
http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html

- Summary: "The foo package does foo": Having redundancy ("the package
  foo") in the summary is useless IMHO, and shouldn't be encouraged.
- Summary: I'd like to see an official suggestion as to whether a trailing
  dot should be added or omitted. If would be prettier when all go by at
  install time :-)
- Requires vs. PreReq: AFAIK, both are now handled identically and using
  PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong.
  For explicit requirements of the %pre/%post scriplets, should the
  "Requires(pre):" way be suggested from now on or not?
- BuildPreReq vs. BuildRequires: Same thing, and it seems even more
  useless to have any kind of distinction for source packages.
- %description and %prep shouldn't be stuck together for readability and
  section separation.
- %makeinstall should probably not be separated from the rest of the
  %install section as it's just a macro, not a separate section.
- The $1, 0 and 1 from the scriplets should either be all or none quoted
  to keep consistent. AFAIK, $1 is always present and is an integer, so
  quoting is not required.
- The %defattr could show the default directory mode too, by using
  %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe)
  as directories might get mode 775 depending on the user's umask.
- The n-e-v-r should maybe be added at the end of the first line of each
  %changelog entry. I don't do it myself (email address too long ;-)),
  but I've noticed it has become common practise inside Red Hat.

It's a nice introduction page to what a spec file is, the descriptions
below are short and clear. Good work!


Now about the guidelines... ;-)

5) "The package may obsolete itself"... I really don't get that one!
6) "If a file from the package conflicts with a file from another package
    in the Red Hat Linux project, the package must use Conflicts: to
    specify it in the spec file."
    Should this be "Conflicts:" with the file or the package name?
12) s/specified/specify/ typo.
13) "If a newer RPM does not have a binary package that the older SRPMS
    produced, the binary package not produced anymore must be specified
    with the Obsoletes: option in the new spec file."
    I would also add something about encouraging to always use versions
    with "Obsoletes:" in order to avoid many kind of future issues when
    re-introducing packages for example.

Also, there is no mention of "Epoch:" usage, not even a quick note to
suggest not introducing any apart from when it's really the last resort. I
guess people may want to stay out of the endless discussion for as long as
possible ;-)
IIRC, I think I read someone mentioning somewhere that a list of current
packages with full "n-e-v-r" would be maintained. With the current
implementation of epoch handling in rpm >= 4.2.1, this will become a
necessity when depending on specific versions of certain packages.

Long mail, hopefully not just useless talk, or else, well... "sorry" ;-)
Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl
Load : 0.24 0.27 0.26