On Mon, Jul 12, 2004 at 09:20:35AM +0100, Alistair Crooks wrote:
> 
> 3. No-one has yet explained to me why we should do this (and, frankly,
> "because FreeBSD has done it" always carries with it lemming-like
> images in my mind. And, yes, I know that Hollywood has given lemmings
> a bad name)

I don't see any useful reason for any particular patch-naming scheme
from a pkgsrc user's standpoint.  However, from a developer's standpoint,
if a patch is linked via a canonical name to the file that it changes,
then the CVS history for a patch will be much more likely to be
relevant.  Currently, when I look at the history for a particular
patch file, I find that, e.g.  patch-ba, has patched any of a number
of files over the course of its existence.  Or vice versa, I find that
a particular file has been patched by several different patches over
the entire history of the package.  It gets even more convoluted when
patches are removed at some point.  The ability to have a useful CVS
history on the changes to a single file without having to read the
histories for every single patch is definitely worthwhile, and I would
support patch names that map to a particular file for that reason
alone.

> > 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. :)
> 
> Well, yes, I have an objection, in principle, to underscores. I don't
> like them. And I don't like them in filenames. Or package names. I
> don't understand why something will only build under Linux with
> embedded underscores. Please explain why this is the case.

On the matter of using underscores, I actually avoid them since
namespace collisions happen more often than you think.  I tend to use
"+" as a reasonably portable path separator these days when I mangle
filenames, though I think if you don't like underscores, then you
probably despise plus signs ;)

> > 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.
> 
> At least with split(1) style names, you are guaranteed a strict
> ordering.  How does moving to mangled names make this any more
> correct?  I can see more problems in this regard with mangled names.

pkgsrc hides the auto* tools from the configure and the build, so
touching files out of order shouldn't matter.  If you find a package
where that seems to fail, please report that as a bug via send-pr(1).

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>