RPM building section of RHL's developer guide
Dams
anvil at livna.org
Tue Jul 22 13:54:14 UTC 2003
I see in the template there is %{buildroot}. I thought JBJ told once
$RPM_BUILD_ROOT was the 'official way' and %{buildroot} might be
changed/removed one day.. According to this, fedora, who firstly used
%{buildroot}, modified [almost] all spec files to use $RPM_BUILD_ROOT
instead... So ? Who is 'wrong' ? What to do ?
D
Le mar 22/07/2003 à 12:26, Matthias Saou a écrit :
> 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
--
Dams Nadé
Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora
I am looking for a job : http://livna.org/~anvil/cv.php
"Dona Nobis Pacem E Dona Eis Requiem". Noir.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20030722/c863ac35/attachment.sig>
More information about the fedora-devel-list
mailing list