Re: Patch name changes

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

On Sat, Jun 12, 2010 at 05:45:52PM +0200, Thomas Klausner 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 don't know about gentoo, but Red Hat always has. This was one of the
big points in rpm vs. dpkg debates in the early days. Debian does too
now, at least sometimes; see for example:

   http://patch-tracker.debian.org/package/ncurses/5.7+20081213-1

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

Yeah, a reimplementation that has knowledge of pkgsrc (this makes it
much simpler than the original quilt...)

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

It only really matters if there are multiple patches that touch the
same file.

I would think it would be fairly easy to have mkpatches detect this
case and abort, something like checking if

   grep '^+++ ' patches/patch-* | awk '{ print $2 }' | sort | uniq -d

is nonempty. And I would think it wouldn't be that hard either to have
mkpatches preserve the structure of the patch files if they don't
overlap, that is, which files are patched by which patch and in what
order. However, as mkpatches appears to be written in perl I can't
help. :-/

With those precautions it's safe to proceed the old way until someone
explicitly reorganizes a package *and* the patches are nontrivial and
overlapping. This is unlikely to happen very much anytime soon.

We could also make it explicit policy that the "pkgsrc config" topic
patch should always be split up per-file. As this is the only topic
patch most packages ever have, this makes it possible to update such
packages's patches by hand or however else.

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

Order matters to quilt, and for pkgquilt it is really really desirable
to retain the behavior that patches are always applied in alphabetical
order. (This simplifies things quite a lot.)

I don't think there's much value to having both kinds at once. I noted
above that splitting the pkgsrc config patch by file might be useful
because often there'll be no other patches; but once there are other
patches (and they overlap) it doesn't help much.

As far as quilt is concerned, an extra per-file patch is just another
patch, and the organizational overhead of having it be separate
devolves onto the user. As far as a non-quilt user is concerned
they'll still run into problems if there are overlapping patches,
regardless of whether some bits are split out per-file.

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