From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110115/002166.html | 135 ++++++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110115/002166.html (limited to 'zarb-ml/mageia-dev/20110115/002166.html') diff --git a/zarb-ml/mageia-dev/20110115/002166.html b/zarb-ml/mageia-dev/20110115/002166.html new file mode 100644 index 000000000..6fa792e39 --- /dev/null +++ b/zarb-ml/mageia-dev/20110115/002166.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] Importing RPM Spec File Syntax + + + + + + + + + +

[Mageia-dev] Importing RPM Spec File Syntax

+ John Balcaen + mikala at mandriva.org +
+ Sat Jan 15 14:01:51 CET 2011 +

+
+ +
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
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1