Op zaterdag 15 januari 2011 14:01:51 schreef John Balcaen: > 2011/1/15 Remy CLOUARD <[email protected]>: > > 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.
