Proposal: - use name of source which patch is apply to. Patch should not fix files from different source. - if is not possible use name of source, use name of package instead.
Well, whatever, I prefer to stick to the package name. Don't think it's really critical, but it must be one of them (source name or package name). Obviously, when there are several original source tarballs, the "name" prefix of the patch should be the name of the source tarball it applies to. I see, but i still think that name of source is better. It is not critical with one source package, though.
1.2.2 Number ------------------ Number as version of source or package is heavily used in patch name.
I never do, I find it rather annoying and misleading. Before building a new version of a package, I check whether the patches still apply. If they do, fine, if they don't, I just port them but keep the [patch] filename. That is exactly point for numbering patches. When patch is numbered, you should investigate if patch is not allready in upstream. All "reasonable" patches should go to upstream.
is updated to new version, all patch had to be updated. In SUSE, there are many packages which contains patch, which are not sent to upstream, because they fix SUSE specific problems. Proposal: - use no number at all for patch which are not meant to be send in upstream (SUSE specific, temporary distribution dependent fix ....) - use number for patch which are only for this version of package (source), this patch should be sent to upstream. This number should be changed when updating to new version if we still expect this patch to be accepted by upstream. If no, number should be removed from this patch.
I won't stick to this one, that's just too complicated, too many if's.
And using a version number in the patch filename has a drawback: when you have to port the patch because the sources don't match, you have to rename the patch file, e.g. from moo-1.2.3-fix-foobar.patch to moo-1.3.8-fix-foobar.patch The problem with that is SCM, as you can't clearly see that you've modified a patch in the change set. It's not as bad with SVN, as you can "svn move" a file to rename it, but it's still a bit tedious. And with CVS, you just don't see it at all and end up with files in Attic. Patch numbering have some drawbacks, everything have. But i still think that is better to do some work when updating, that do a lot of work searching every patch what to do. The if`s are really sample actually. If this fix is "SUSE only" (menu, file position, icons ...) no number. If patch have number, it should be send to upstream..
- there are patch which fix problem which is caused by another part of system ( broken library, autobuild....). Patch name should reflect this. We propose to use buildfix/temporaryfix/runfix for such patch. This patch should be removed as soon as possible (probably when updating to new version) buildfix - if this package could be builded, this patch could be safely removed. runfix - if this package could be runed without this patch, this patch could be safely removed. temporaryfix - all other temporary fix.
How is a fix "temporary" ? As long as it isn't fixed upstream, a patch is necessary, doesn't matter whether it's for the build system or for real sources. There are cases when package is broken because of error in other package(s). This is really special case. Such a fix is neither meant to be sent to upstream, nor stay with package for long time.
Comment should be also used, if patch is used differently than normal. e.g. (blender) Patch1: po.patch
^^^^^^^^^^^^^^^^^^^^^^^^ <nitpicking> Hey, that one doesn't comply to your proposal ;D Should be %{name}-po-fix-typos.patch </nitpicking> You are right. This is "old" patch. Before proposal ;-)
Patch2: blender-home-to-datadir.patch # patch is applied only on x86-64 Patch5: Scons.patch [...]
(same nitpicking as above ;)) Same as above.