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
signature.asc
Description: This is a digitally signed message part.