Re: Patch name changes

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Thu, Jun 10, 2010 at 07:07:32PM +0000, David Holland wrote:
> 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.

What kind of globs do you use on your patch-directory?
What exactly is the problem you're seeing? How would it change with
this naming change?

> 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 agree it would be nice.

> 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.

And I think that's exactly the problem we'd be seeing with
patches-per-topic. It's perhaps not so hard to create a new patch
that's per topic, but for package updates, I don't see how it can be
automated in any meaningful way -- and I think package updates are the
most common reason for changes in pkgsrc.

> 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.

Perhaps you can explain how this would help in updating a package?

> 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.

Since each file is only patched once, we don't care about application
order (staying with patch-per-file, which is what I was suggesting).

>  > 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.

mkpatches already keeps comments, but it seems some people are not
using it. If we let pkglint complain about missing comments, that will
be much easier to see for them...
 Thomas