Re: Patch name changes

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Thu, Jun 10, 2010 at 12:14 PM, Thomas Klausner <wiz%netbsd.org@localhost> 
wrote:
>
> Hi!
>
> I would like to suggest that we change the names used for patches in
> pkgsrc.
> Currently, their names are patch-[a-z][a-z] where the names are more
> or less chosen randomly; when upgrading, usually care is taken to use
> the same patch name to modify the same file as before (mkpatches(1)
> from pkgtools/pkgdiff does that automatically).
>
> I suggest we starting from now on, we use the name
> patch-path_relative_to_wrksrc_filename instead, i.e. run the path of
> the name of the file to patch through
>        sed -e "s,_,__,g"  -e "s,/,_,g"
> and prefix "patch-".
>
> Since sometimes interesting comments/reasons for the patches hide in
> the CVS history, I'd prefer not to rename the existing patches and
> just use the syntax for new patches.
>
> Dillo and/or I will improve mkpatches to handle this automatically.
>
> This makes it easier to see from the file system, what files are
> patched; it also helps packagers of other porting systems to more
> easily identify e.g. from cvsweb at which files to look.

If we are to change the way patches are stored, could we consider all
options?  Patching by file make sense in *some* cases, but I think
it's the wrong approach altogether.

When we apply a patch, we do it for a specific purpose.  The patch
reflects a feature fix or addition, and it may affect one or more
files.  I.e., if we call one of these patches "patch-configure", we
are using the wrong grouping level.  Such a patch may include pkgsrc
specific and non-specific options; how do you feed such patch
upstream?

If instead we name the patches by purpose, such
aspatch-fix-configure-portabilty, patch-add-enable-debug-flag, etc.,
then it's much easier to feed such patches upstream.  And, in most
cases, that makes the comment redundant/unnecessary.

Sure, such patches are harder to manage.  For one, you cannot generate
their naming automatically.  And for other, the application order
matters (not that this would affect pkgsrc much though).  I've found
that devel/quilt does wonders in managing such patchsets.

What would people think about such approach?

--
Julio Merino