Re: patch filenames

["Julio M. Merino Vidal" <jmerino%ac.upc.edu@localhost>]

On 07/01/2008, at 0:36, Dieter Baron wrote:

> In article <1A0334EC-7DF9-4644-94B0-28473E0CA86C%gmail.com@localhost> Julio  
> wrote:
> : Except that 3 makes it much easier to feed things back upstream,
> : while 2 does not at all when you patch a single file for multiple
> : different reasons (being configure the most common example).
>
> : To solve the order problem, we'd add a "series" file alongside the
> : patches that lists the patch names and thus imposes order among
> : them.  Then it'd be trivial to use quilt to manage these patch sets,
> : which is a pretty nice tool when you get used to it :-)
>
>   pkgsrc is complicated enough without adding extra complexity with
> patch handling.
>
>   Currently, the .orig files contain the original version of the file,
> and tools like pkgvi and pkgdiff can do their work.  Julio: How do you
> propose to deal with that when patching one file multiple times?

Maybe I'm too quilt-biased, but think of quilt as a much more  
advanced version of pkgvi and pkgdiff.  With quilt you can easily  
manage a series of patches.  For example, suppose you want to modify  
the sources to fix two different problems, and each of them affects  
different (possibly overlapping) files:

$ quilt new fix-libfoo-detection.diff
$ quilt edit configure.ac
...
$ quilt edit configure
...
$ quilt edit foo.h
...
$ vi configure.ac (further edits do not need quilt edit).
...
$ quilt refresh
$ quilt new fix-netbsd-cpp-checks.diff
$ quilt edit foo.h
...
$ quilt edit bar.h
...
$ quilt refresh

There you have two different patches (which are stored automatically  
in a patches directory).  You can move between them (apply or unapply  
them) by using quilt push and quilt pop respectively, and regenerate  
as will.  quilt also takes care to manage that "series" file I  
mentioned, which is in fact required to know the order in which  
patches need to be applied.  Plus it has nice handling when patches  
get out of sync and fail to apply.

Additionally, you can easily manage the patch  
"headers" (descriptions).  If we had self-contained patches with  
proper explanations in them, then that "feedback-patches" utility  
someone mentioned the other day could work pretty well.  Otherwise it  
is very difficult for the patches that currently lie in pkgsrc to be  
sent to upstream.  (I personally have had to recreate many, many  
patches from scratch when sending them to the mainstream developers  
because the pkgsrc versions were unsuitable to be sent.)

Plus, with this approach, patches could get descriptive names of  
their *purpose*, not the file they patch.

But well, managing this kind of patches manually can be a nightmare.   
In the above, I always had quilt in mind, or improved versions of  
pkgdiff.  See devel/quilt for more details.

Cheers,

--
Julio M. Merino Vidal <jmmv84%gmail.com@localhost>


--
Julio M. Merino Vidal <jmerino%ac.upc.edu@localhost>