Re: Patch name changes

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Thu, Jun 10, 2010 at 01:14:33PM +0200, Thomas Klausner wrote:
 > I would like to suggest that we change the names used for patches in
 > pkgsrc.
 > 
 > 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-".

I don't think this is a good idea. A few packages already follow this
model (or some approximation of it) and IME it doesn't really make
updating any easier; it just makes it somewhat harder to work with the
patch directory by e.g. making it harder to write shell globs that
exclude editor backup files.

In any case, I think it's moving in the wrong direction.

Currently we have one patch per source file, which is necessary
because of the technical limitations of e.g. mkpatches. However, for
most purposes it's much more desirable to have one patch per topic
(DESTDIR support, pkgsrc config, 64-bit cleanliness, etc.)

Such an organization groups all related changes together for easy
inspection and submission upstream. It also makes it much easier to
split related changes out into a distfile patch.

I've tried three times now to wrangle the 234 patches in xview, the
intent being to move most of the changes to one or more distfile
patches. In order for that to be useful in the long run the changes
need to be sorted by topic; getting there without accidentally losing
any bits turns out to be a nontrivial problem.

In order to avoid generating any further such situations (we have
nothing else like xview, but I see 14 other packages with more than 50
patches) I think we should be spending our effort on moving to one
patch per topic.

To this end I'm about halfway through writing a pkgsrc implementation
of quilt, that could be used instead of mkpatches to support this
model. It is not ready for anyone else to look at yet, but I can
probably turn out a testable version this weekend.

In any event, if we really want long patch names, they should be
patch-aa-mumble, not just patch-mumble, or the application order will
depend on locale settings and case-sensitivity and other horrors,
which will inevitably lead to weird problems.

 > Dillo and/or I will improve mkpatches to handle this automatically.

Can you also fix mkpatches to not throw away comments, or do something
to persuade people who are (apparently) using old versions that do to
not do so? I have several times seen subsequent commits blithely erase
patch comments I'd added.

-- 
David A. Holland
dholland%netbsd.org@localhost