Re: Patch name changes

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

On Fri, Jun 11, 2010 at 09:42:15AM +0100, Julio Merino wrote:
> That's something the tools have to deal with, not the model.  The
> underlying model for the patches should be correct in the first place.
> I'm not completely sure about if any other packaging system manages
> patches by topic, but it'd be a very nice advantage for us.  (I know
> ports don't, and I know debian package do not either, to say a
> couple.)

Doesn't gentoo do it?

> I'm not advocating using directly devel/quilt, but here is how it
> works.  We may want to "fix" it to not rely on gnu-specific tools (to
> keep the dependencies very simple), or write our own custom version
> (*shrug* why would we do that?).  Note that quilt is what was used
> before git to prepare patchsets against the linux kernel tree, so it
> is widely tested and it is proven to work for maintaining custom patch
> sets.  It also has some features to automatically send patchsets to
> upstream (quilt mail).

[...]

Thanks for the explanation. That really looks like a useful tool, and
I have no problem using it (or something similar, dholland@ is working
on something?) for pkgsrc.

I think it will be overkill for many packages though where a simple
patch-per-file is sufficient. Perhaps we can come up with something
(naming convention?) that allows us to have both in pkgsrc, depending
on the package. This way it's also not necessary for all pkgsrc
developers to learn quilt at the same time.

I.e. something like
patch-quilt-100-fix-deprecated-symbols
patch-quilt-200-get-rid-of-annoying-stuff
patch-quilt-250-add-cool-stuff (added after the next one)
patch-quilt-300-more-cool-stuff
patch-path_to_file
patch-path_to_some_other_file

and apply them in the order shown above (quilt ones by number, other
ones after quilt ones, but order doesn't matter).

Would something like this work? I don't know enough about quilt yet...

Thanks,
 Thomas