Christian Boltz wrote:
Well, it depends ;-)
Yes. ;-)
Let's say you have a patch that fixes a bug in foo 1.2.4, and that bug is also fixed upstream in the next (not yet available) release. In this case, it makes sense to include the version number in the patch, for example foo-1.2.4-fix-crash.patch so that you can easily spot "outdated" and no longer needed patches.
If there's a bug in foo 1.2.4 *and* you know for sure this is fixed in already released foo 1.2.5 then it's ok to use the version number. In all other cases the version number IMO does not even give a hint about whether it's still needed or not. At least that's my experience when branching a package for an upstream update. IMO it does make much more sense to add a reference to a tracker ID for pointing to a description of the issue fixed by the patch.
Another option is to have a comment line for each patch in the spec,
Even more nice. :-) And a comment that a (back-port) patch is really obsolete when upgrading to next upstream release would be perfect.
Independent on the naming scheme - a package with 2 patches will be easy to maintain even if you have a "bugfix.patch" and "bugfix2.patch", and a package with 100 patches will be a maintenance nightmare even if you have self-explaining patch names ;-)
I totally agree here. I consider a package with more than a dozen patches to be very questionable anyway because of the maintenance nightmare leading to more small patches instead of proper upstream upgrading. Ciao, Michael.