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/002173.html | 116 ++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110115/002173.html (limited to 'zarb-ml/mageia-dev/20110115/002173.html') diff --git a/zarb-ml/mageia-dev/20110115/002173.html b/zarb-ml/mageia-dev/20110115/002173.html new file mode 100644 index 000000000..7211cc455 --- /dev/null +++ b/zarb-ml/mageia-dev/20110115/002173.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Importing RPM Spec File Syntax + + + + + + + + + +

[Mageia-dev] Importing RPM Spec File Syntax

+ Angelo Naselli + anaselli at linux.it +
+ Sat Jan 15 20:15:16 CET 2011 +

+
+ +
Hi,
+> 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'
+Sorry I can't get this...  I mean i'm packaging foo, the spec file
+is for foo the patch is under foo svn directroy, is invoked by
+foo.spec... so what's the matter in that?
+
+>   * [version] is the version of the program this patch was developed
+>   against, such as 1.0. 
+hmm in a first view i seconded it, but after a while again i can't see really
+why. I mean if a patch has been added into version 1.0 you can only
+know when has been added not if it's still valid. 
+>   The name of the patch should not change, even
+>   when it is rediffed, because the version allow to see in a blink since
+But here if you changed the patch because of rediffing, it's not true that is
+for version 1.0, but for the new one. Otoh changing the name, means moving or
+deleting-adding a new patch under svn... So again no reason to add this field 
+-imo of course-.
+>   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.
+Good point. That should be always asked for since the patch was added by
+the packagers, but in my experienced i had packages in which passing upstream
+patches was very hard if not impossible.
+
+>   * [description] is a short description of the patch's purpose.
+iirc there is a -b option to be passed to %patch in which you can add
+a string and again iirc that was used by packagers for a brief description
+so 
+%patch0 -b string_format 
+is at least clear as your example
+That also creates, iirc again, files used in patch with their name and 
+string_format suffix   (e.g. foo.c -> foo.c.string_format or similar).
+> Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format
+> errors
+in both cases your and mine (str-fmt and string_format) it's clear for
+the one who added the patch not the one who handles the package after,
+because the real point is not the patch itself but the reason of submitting it
+i believe.
+
+Maybe some comments concerning the patch and the patch reason could be
+clearer than few chars in a string name :)
+
+Just my thought of course :)
+
+Cheers,
+	
+-- 
+	Angelo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110115/8bbe8206/attachment.asc>
+
+ + + +
+

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