Patch Tagging Guidelines standardized in Debian as DEP3

[Solar Designer]

On Fri, Jun 19, 2009 at 04:08:31PM +0200, Vincent Untz wrote:
> Le vendredi 19 juin 2009, ? 11:18 +0200, Raphael Hertzog a ?crit :
> > Check out the discussion here:
> > http://lists.debian.org/debian-devel/2009/06/msg00458.html
> > 
> > And the current draft is here:
> > http://dep.debian.net/deps/dep3/
> 
> I don't have much time to look at this right now, just want you to know
> that we use http://en.opensuse.org/Packaging/Patches for openSUSE.

FWIW, we also have a relevant convention, embedding some meta-info in
patch file names.  The convention is a bit dated, though (e.g., the
references to "CVS" should be made more generic).

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/doc/CONVENTIONS?rev=HEAD

Here's the relevant excerpt:

	Patch file naming.

Use the following syntax for patch file names:

	NAME-VERSION-ORIGIN-WHAT.diff

where NAME and VERSION are the package name and version, ORIGIN is an
abbreviation of the distribution name(s) the patch originates from,
and WHAT is a description of what the patch is for or what it does.

If a single patch file is based on pieces from more than one
distribution, all are to be included in ORIGIN, most relevant first.
For patches developed as a part of Owl, ORIGIN is to be set to "owl".
If a patch is derived from another distribution but with significant
changes applied, ORIGIN should include "-owl-" as well (which would
indicate that any bugs are ours).  If a patch has been extracted from
the primary CVS repository for the package in question (for example,
this may be the case for various back-ports), ORIGIN should be set to
"cvs" and WHAT to the date it corresponds to (as YYYYMMDD) plus the
usual description of the patch.  Patches from upstream maintainers
that aren't (yet?) in the primary CVS repository (if one even exists)
may have ORIGIN set to "up".

For multi-word WHATs, separate the words with dashes.  Do not use
underscores except when referring to an existing identifier (in which
case the identifier is to be quoted verbatim, including any possible
underscores and uppercase letters).

There are also some common WHATs to use whenever applicable:

Makefile	- Makefile* patches only (note the capitalization)
bound		- bound checking (buffer and/or integer overflow fixes)
config		- configuration files patches only (compile- or runtime)
doc		- documentation patches only
env		- environment variable handling fixes
fixes		- cumulative bug, reliability, and/or security patches
format		- printf-style format string fixes (not only security)
info		- texinfo documentation patches only
install-no-root	- changes to run "make install" or equivalent as non-root
linux		- changes needed to build on Linux (for ported software)
man		- man page patches only
tmp		- patches dealing with temporary file handling issues
vitmp		- patches that add vitmp(1) support
warnings	- compilation warning fixes only

This is NOT to suggest you should try to arrange your modifications
such that the patch files fit one of these categories.  In fact, it is
often preferable to do things differently.  This is just to say that
if you happen to have a patch file that matches one of the categories,
name it accordingly (such as, "tmp" and not, say, "mkstemp").

Here are some examples:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/vsftpd/
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/cdrkit/
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/pcre/
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/pam/
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/openssl/

In a few patch files, we also use the lines prior to the start of the
actual patch, but we have no standard on that.  Perhaps this is a better
way to encode additional meta-info, because filenames shouldn't get too
long and because it is inconvenient to have to rename patch files
whenever the meta-info changes.  Yet I thought I'd share the convention
we've been using so far.

Alexander