[Mageia-dev] Importing RPM Spec File Syntax

Sat Jan 15 14:10:08 CET 2011

Op zaterdag 15 januari 2011 14:01:51 schreef 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:
+>  #
+
+git-svn patches have description automatically, if that format is also ok, i 
+see no reason why not.
+
+perhaps some emphasis on git-svn should be made on the wiki, relating to 
+patches.
+
+> > - 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,
+
+Personally, i agree regarding the %files part to be under their respective 
+%description and having build stuff on the bottom part. I like that idea.
+
+regarding defines, i don't understand completely, but i am in favor of having 
+all defines up top.
+