Re: Reducing the number of patches in pkgsrc

[Klaus Heinz <k.heinz%janacht.kh-22.de@localhost>]

Greg Troxel wrote:

> It might also make sense to have a machine-parseable format for
> recording upstream tracking status in patch files, or to record that it
> is a pkgsrc change (e.g., examples/conf file installation).  Then
> pkglint could warn when there isn't a recorded status for a patch.

_Very_ strongly seconded. From what I have seen, many patches just
hard-code something appropriate for pkgsrc.
In the case of patches for pkgsrc-specific reasons this is anavoidable and
the patch will always be there.
In other cases it is just the easiest way to make the package buildable
with pkgsrc but is very hard to maintain in the long term because it cannot
get integrated in the original source. In those cases, The Right Thing To
Do (tm) would be to add some configurable option (eg,
"--path-to-foo=/somewhere/pkgsrc/foo" for autoconf scripts) and submit
_this_ patch to the software author.
Of course, this way of creating patches is more complex and trying to
get patches integrated often takes considerable time, if possible at
all.

> The hard part is probably that some upstreams aren't really interested
> in taking patches to fix problems from pkgsrc, or are overwhelmed.
> But we might as well do our part and try to reduce where we can.

IMO we must reduce the number of patches. Often it is not clear why a patch
is even there. CVS history is often useless because updates to patches
mostly belong to some general update of the package with a CVS message
like "update of foo to verson x.y". What is the meaning of those changed
patches? Impossible to tell from CVS history.

ciao
     Klaus