I'm late to the party here, I think, but here goes!
This renaming of patch files in pkgsrc has been something I've been
doing myself for some time now, and I too have wanted to suggest it be
done officially.
One major driving force for me has been that the stupid unnecessary
churn in patch content vs. patch filename has been driving me crazy for
literally years now.
All the other reasons that have been given in this thread are all very
good as well.
I would of course also support the idea of creating "change" or "topic"
based patch files, but in reality they aren't of much use in pkgsrc
itself. They do have the advantage that they are easier to maintain in
conjunction with upstream changes. Using an existing, and relatively
well known, tool like "quilt" would make this even easier and more
robust.
I'm really very happy to see this discussion!
At Thu, 10 Jun 2010 20:58:36 +0200, Thomas Klausner <wiz%NetBSD.org@localhost>
wrote:
Subject: Re: Patch name changes
>
> On Thu, Jun 10, 2010 at 08:01:57PM +0200, Alistair Crooks wrote:
> > Interesting syntax - is there any prior art for this kind of naming scheme?
>
> Yes, both FreeBSD and OpenBSD use it.
As far as I can tell FreeBSD "ports" prefers to use a double-colon to
replace the "/", as in this example:
net/freeradius-client/files/patch-configure
net/freeradius-client/files/patch-configure.in
net/freeradius-client/files/patch-lib::config.c
net/freeradius-client/files/patch-lib::ip_util.c
net/freeradius-client/files/patch-lib::options.h
net/freeradius-client/files/patch-lib::sendserver.c
Apparently Johan Vromans' makepatch utility (a Perl script) is used, or
is preferred to be used, to generate the patches in FreeBSD Ports.
There is some slightly confusing verbiage in the porters-handbook
though, i.e. on this page:
http://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html
about patch names, but their repo shows lots of examples like I gave.
All that's moot though if pkgsrc uses some quilt-like tool for
topic-based patches instead.
Note also that they've removed the unnecessary "patches" sub-directory
and instead moved patch-* files into the "files" sub-directory. I'm not
sure there are that many "files" sub-directories (i.e. that doing this
actually saves many directories in the tree), but what it does do is
make the version control history changeover more abrupt and obvious.
(though this might be too complex if the migration is done slowly)
However if the patch files are kept in the "patches" sub-directory then
I'd strongly suggest dropping the "patch-" prefix to the name as well.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgppN2NLnE_OD.pgp
Description: PGP signature