Subject: Re: [change request] pattern for patch filenames
To: Roland Illig <firstname.lastname@example.org>
From: Julio M. Merino Vidal <email@example.com>
Date: 07/09/2004 18:42:32
On Fri, 09 Jul 2004 18:23:00 +0200
Roland Illig <firstname.lastname@example.org> wrote:
> Having the underscore character in the patch name pattern:
> - I (Roland) would like it
> (mainly to automatize the creation of patches)
Just for the record: patches can now be generated automatically. See the
mkpatches utility in pkgdiff. Extending it to choose names which match
existing patches shouldn't be very difficult. It's not the addition of the
filename in the names that makes it possible; just easier.
> - lukem thought this idea to be a good one
> Naming scheme for patch files:
> - grant would rather name the patches by function
My preference could be that they contain the filename in them. Grouping by
function will lead to multiple files patched from a single file... and
anyway we can always add a small comment on top of the patch explaining what
> So we have two different discussion points here. Are there any opinions
> against allowing the underscore in patch file names? If not, I would
> like this change to happen, as I already have many packages that would
> immediately build under Linux if only the patch names were allowed. :)
Things should happen the other way around. First get the change done, then
change existing packages accordingly. If not, your packages are simply broken
to other users and are not correct to pkgsrc's POV.
> The other point (the naming scheme) is important, too. I noticed that
> with encoding the file name as the patch name the order in which the
> patches are applied only depends on the file name, not on the package
> maintainer's opinion. There might be problems with dependent files, such
> as ./configure and ./configure.ac, as well as lex and yacc files.
> These alternatives came to my mind:
> - only patching the relevant file (./configure) and letting
> ./configure.ac untouched
> This should cause no problems unless the package rebuilds ./configure
> during the build.
If configure.ac is patched, it's probably because you'll re-run autoconf
later. If not (in the very few exceptions), a simple 'touch' after patch
should be enough.
Julio M. Merino Vidal <email@example.com>
The NetBSD Project - http://www.NetBSD.org/