Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
Re: [opensuse-packaging] Patches naming (include source version?)

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.

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

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 <

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
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,
makes more sense than
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

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 ;-)


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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >