[Mageia-dev] Importing RPM Spec File Syntax

[John Balcaen]

2011/1/15 Remy CLOUARD <shikamaru at mandriva.org>:
> Hi there,
Hello,
> I just imported the RPM Spec File Syntax page in the wiki.
>
> It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax
>
> Please review this page as it’s one of the most important one for the
> beginning of the mentoring process, with the RPM Howto page (yet to be
> imported).
>
> Some comments on this page:
> - Patch naming:
>
> I’m not sure we should go that far for the patch naming policy, and in
> practice it’s not what I’ve seen up till now.
>
> Here’s a proposal:
> Patches must be named in a very explicit manner to make it very clear to
> what version it was originally applied. To that end, a patch needs to
> follow the convention of
> [package_name]-[version]-[description].patch:
>
>  * [package_name] is the name of the package it applies against, such
>  as 'shadow-utils' or 'gnupg'
>  * [version] is the version of the program this patch was developed
>  against, such as 1.0. The name of the patch should not change, even
>  when it is rediffed, because the version allow to see in a blink since
>  when this patch has been there. If you happen to see a patch that does
>  not apply anymore, and rediff it, ask the package maintainer if it has
>  been sent upstream, and why it hasn’t been merged, and send it
>  upstream if you think it should be merged.
>  * [description] is a short description of the patch's purpose.
>
> Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format
> errors

It would also be nice to add some comment inside like we're trying to do in
our kde's packaging policy (
http://www.mageia.org/wiki/doku.php?id=kde4_packaging_policy )
aka
#
 # Description:
 # Forwarded:
 # Bug:
 # Author:
 #



> - Buildroot changed from the original page

> After reviewing it again, I see that some links have to be made to the
> corresponding pages, and an explicit license should be mentionned as
> well.
>
[...]
Regarding the spec we've got at least a major difference in our kde's spec
For example not all the %define are localized at the top of the spec,especially
thoses for macro & libname : it's  easier for me to have some of them in the
same part.Maybe it's due to our will massive libification, but having
more then 15
%define for macro & libname without knowing  which package is affected.
Also maybe others can find useful to have the %files list for every
package listed
under their description (instead of having all of them after the
%prep,%build etc part )

Regards,





-- 
Balcaen John
Jabber-Id: mikala at jabber.littleboboy.net