[opensuse-packaging] Patches naming (include source version?)
Hello. What is the rule for naming patches? I mean including or not a version of a source in the name. Following https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_naming "Do NOT use %{version} macro in Patch: line, specify the version by hand." A patch will look like foo-1.2.3-fix_something.patch. Is it still valid? I see a lot of patches without a version in their names. What is the right way? I prefer to have a version in a patch name to know that foo-1.2.4-fix_something.patch is applied for "foo = 1.2.4" and, possibly, for "foo > 1.2.4". And it isn't applied for "foo < 1.2.4". -- WBR Kyrill
Hello, Am Dienstag, 3. Februar 2015 schrieb Kyrill Detinov:
What is the rule for naming patches? I mean including or not a version of a source in the name.
Following https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_na ming "Do NOT use %{version} macro in Patch: line, specify the version by hand." A patch will look like foo-1.2.3-fix_something.patch.
Is it still valid?
The advice not to use the %{version} macro in a patch name is still valid, because otherwise you'd have to rename the patch each time the version number changes. Note that the guidelines doesn't say that you should or should not include the version number in the patch name. It only says that you should avoid using the %{version} macro.
I see a lot of patches without a version in their names.
I wouldn't call that a problem.
What is the right way? I prefer to have a version in a patch name to know that foo-1.2.4-fix_something.patch is applied for "foo = 1.2.4" and, possibly, for "foo > 1.2.4". And it isn't applied for "foo < 1.2.4".
Well, it depends ;-) 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. OTOH, I'd avoid the version number in patches that aren't meant to go upstream (for example some changes in a config file so that it better fits for openSUSE) and will probably stay in the openSUSE package forever. For example, foo-set-packager-to-zypper.patch makes more sense than foo-1.0.1-set-packager-to-zypper.patch which looks a bit strange when the package version number increases. Another option is to have a comment line for each patch in the spec, like I do in the AppArmor package. This has the advantage that it's easy to update (compared to hardcoding version information in the patch filename). That said - these are just my personal rules of thumb - if you like them, feel free to use them ;-) Oh, and it's a good thing that we don't have strong rules for every little detail. Common sense is enough, and in the end the package maintainer can use the naming scheme that fits his workflow best. 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 ;-) Regards, Christian Boltz -- BUGS My programs never have bugs. They just develop random features. If you discover such a feature and you want it to be removed: please send me an email. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello. On Tue, 03 Feb 2015 21:32:11 +0100 Christian Boltz wrote:
The advice not to use the %{version} macro in a patch name is still valid, because otherwise you'd have to rename the patch each time the version number changes.
This is clear.
Note that the guidelines doesn't say that you should or should not include the version number in the patch name. It only says that you should avoid using the %{version} macro.
I remember, there was an instruction to name patches versioning. I can't find the source now. "Do NOT use %{version} macro in Patch: line, specify the version by hand." — it looks alternative: either "%{version}" or version [by hand].
What is the right way? I prefer to have a version in a patch name to know that foo-1.2.4-fix_something.patch is applied for "foo = 1.2.4" and, possibly, for "foo > 1.2.4". And it isn't applied for "foo < 1.2.4".
Well, it depends ;-)
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.
OTOH, I'd avoid the version number in patches that aren't meant to go upstream (for example some changes in a config file so that it better fits for openSUSE) and will probably stay in the openSUSE package forever. For example, foo-set-packager-to-zypper.patch makes more sense than foo-1.0.1-set-packager-to-zypper.patch which looks a bit strange when the package version number increases.
I'm not sure here. A quick investigation shows: https://build.opensuse.org/package/show/Base:System/at https://build.opensuse.org/package/show/Base:System/bash https://build.opensuse.org/package/show/Base:System/bc https://build.opensuse.org/package/show/Base:System/bluez
Another option is to have a comment line for each patch in the spec,
I totally agree. And this requirement is described in https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Type_1:_minima... -- WBR Kyrill
On Wednesday 04 of February 2015 01:39:59 Kyrill Detinov wrote:
I remember, there was an instruction to name patches versioning. I can't find the source now. "Do NOT use %{version} macro in Patch: line, specify the version by hand." — it looks alternative: either "%{version}" or version [by hand].
I always understood this rather as "if you want to include version in patch name, use a fixed string, not %{version} macro", i.e. not telling you to include version but how to do it if you decide to.
I'm not sure here. A quick investigation shows: https://build.opensuse.org/package/show/Base:System/at https://build.opensuse.org/package/show/Base:System/bash https://build.opensuse.org/package/show/Base:System/bc https://build.opensuse.org/package/show/Base:System/bluez
My guess is this is mostly a relict of old days when one often had multiple sources unpacked in one SOURCES directory so that naming all patches and sources prefixed with package name was a useful trick to avoid collision and distinguish which package does the patch belong to. Today, one has separate directories for OBS packages so that it's clear from the context what package does the patch belong to and duplicating that information in patch file name would be superfluous. However, it doesn't harm anything and old habits die hard so that many packages keep this convention. Others generate their patches from git repositories and use names generated by "git format-patch". You can even find packages where old patches follow the traditional name - version - shortcut scheme and newer ones have git generated names. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 04 Feb 2015 06:41:02 +0100 Michal Kubecek wrote:
I'm not sure here. A quick investigation shows: https://build.opensuse.org/package/show/Base:System/at https://build.opensuse.org/package/show/Base:System/bash https://build.opensuse.org/package/show/Base:System/bc https://build.opensuse.org/package/show/Base:System/bluez
My guess is this is mostly a relict of old days when one often had multiple sources unpacked in one SOURCES directory so that naming all patches and sources prefixed with package name was a useful trick to avoid collision and distinguish which package does the patch belong to.
Sounds reasonably. I almost agreed, but … just found the commit in "New Tumbleweed snapshot 20150204 released!"
==== xosview ====
- Rename patches xosview-appdef.patch becomes xosview-1.16-appdef.patch xosview-configuration.patch becomes xosview-1.16.dif xosview-diskstat.patch becomes xosview-1.16-diskstat.patch xosview-serial.patch becomes xosview-1.16-serial.patch
-- WBR Kyrill
* Dne Středa 4. únor 2015, 06:41:02 [CET] Michal Kubecek napsal:
On Wednesday 04 of February 2015 01:39:59 Kyrill Detinov wrote:
I remember, there was an instruction to name patches versioning. I can't find the source now. "Do NOT use %{version} macro in Patch: line, specify the version by hand." — it looks alternative: either "%{version}" or version [by hand].
I always understood this rather as "if you want to include version in patch name, use a fixed string, not %{version} macro", i.e. not telling you to include version but how to do it if you decide to.
I'm not sure here. A quick investigation shows: https://build.opensuse.org/package/show/Base:System/at https://build.opensuse.org/package/show/Base:System/bash https://build.opensuse.org/package/show/Base:System/bc https://build.opensuse.org/package/show/Base:System/bluez
My guess is this is mostly a relict of old days when one often had multiple sources unpacked in one SOURCES directory so that naming all patches and sources prefixed with package name was a useful trick to avoid collision and distinguish which package does the patch belong to.
There was also sometimes a guideline that the version number in the patch should indicate the tarball version against which was the patch refreshed/based. -- Vita Cizek
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.
Hello, On Feb 4 14:20 Michael Ströder wrote (excerpt):
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 this special case one could even use in the spec file the "forbidden" form Patch123: foo-%{version}-backported_fix.diff to let it intentionally break early if that Patch123 still exists after a version upgrade (the crucial word is "early"). This is only meant as an example for hwo much "it depends". Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
participants (6)
-
Christian Boltz -
Johannes Meixner -
Kyrill Detinov -
Michael Ströder -
Michal Kubecek -
Vitezslav Cizek