Date: Tue, 21 Dec 2010 18:30:42 +0300 From: Eygene Ryabinkin <rea@freebsd.org> To: freebsd-ports@freebsd.org Cc: Olli Hauer <ohauer@FreeBSD.org> Subject: RFC: 'make makepatch' and alternatives Message-ID: <UDRFs2KOaLBhFHwZEOP2PeOmgxo@QsmfhJNucgI88DfvPJdT1/nyboE>
next in thread | raw e-mail | index | archive | help
Greetings!
I had a dispute with Olli Hauer about the usage of the 'makepatch'
target for generating port patchfiles.
I am currently using patchfiles for my ports that are generated by the
version control systems and are grouped by-commit. But there is an old,
good makepatch target that creates per-file diffs based on all applied
patches.
Section 4.4 of Porters Handbook says that there should be no two patch
files that modify the single source file, so, in general, my approach is
a kind of herecy. As I understand, there are just two sound reasons to
use the makepatch:
- one has no need to worry about the patch order: hunks are
grouped by-file, so any patch order will go;
- one can simply invoke 'make makepatch' to produce all patchfiles
automatically after the virgin sources were patched and .orig
files were left in place.
There is the third reason from the Porters Handbook: "To make fixes and
upgrades easier, you should avoid having more than one patch fix the
same file", but frankly, I don't quite understand its meaning, apart
=66rom the reasoning in the point 1 raised above.
=46rom the other hand, by-commit patchfiles have the good property that
they carry the vital metadata: the grouping of hunks and, in some
cases, the comments about the patch itself (Git patches are good example
of this). And, if the author of the patch makes a reasonable effort
to make single commits to be grouped by-topic (rather than squelching
multiple unrelated or loosely related modifications into a single
commit), such metadata is rather useful both for maintainer and persons
who will add/modify port patches. Here are my reasons:
- suppose, one is upgrading the port from version X to version Y
and he finds that the patch A doesn't apply; the most common reasons
for this are
a) upstream sources were changed in some non-trivial way, but
there is still a need to patch, but the original one should
be modified for the new version;
b) the patch was taken upstream (perhaps, with some modifications,
but there is no need to modify the original patch, since the
original problem was fixed, but, may be, in the different way);
In either case, by-commit grouping will permit the porter to immediately
identify the hunks that should be either thrown out or modified;
with the by-file approach, one will need to identify all hunks in
different patchfiles that are related to the said modification;
- suppose, the non-maintainer has to create new patch for the port
because he want to fix some problem, upgrade the port or for some
other reason; he looks into the files/ directory and sees a bunch
of patch files with a bunch of hunks inside each, but he can't
easily track their interrelations -- a time should be spent to
figure out what hunks serve what purpose. By-commit patchfiles
have no such problem -- the metadata is already here.
Olli said to me that by-file grouping makes it easier to understand
what files were patched. That's true, but it is not so hard to
get this information from the by-commit patchfiles: it is a trivial
scripting that can be added to the bsd.port.mk (I can provide it
if it is really needed).
And, transforming the by-commit patches into by-file is a loss of
data in a strict mathematical sense: transformation by-commit ->
by-file has no single inverse function, there are multiple variants
how by-file hunks can be regrouped into by-commit ones.
There is a slight problem with the by-commit patches: their order
can matter, but if _PATCHFILES inside bsd.port.mk will be sorted
alphabetically, then a simple naming like 'patch-NNNN[abcd]-whatever'
will be sufficient: suppose there are already patches
{{{
patch-0001-fix-one
patch-0002-fix-two
patch-0003-fix-three
}}}
and we want to insert another patch between 2nd and 3rd. The name
like "patch-0002a-fix-two-prime" will do the trick.
I am obviously not trying to force anyone to move to the by-commit
patchfiles, but I just want to know
- if I am missing something with the generally-adopted scheme with
"make makepatch"
- if it seems reasonable to other people to employ the by-commit patch
grouping.
--=20
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?UDRFs2KOaLBhFHwZEOP2PeOmgxo>