tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Reducing the number of patches in pkgsrc

On 05/01/2008, at 18:42, Klaus Heinz wrote:

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.

Even patches that seem pkgsrc-specific can often be generalized enough to be fed back to developers. One of such examples is the hardcoding of subdirectories under sysconfdir: some packages currently just mess with that, hardcoding other values, but a different approach is to rework the configure script and source code to make that subdirectory name configurable and then default to the current behavior. This way they easily get accepted by upstream :-) But it surely is more work on our part.

I guess similar approaches are applicable to other pkgsrc-specific situations.

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.

Very true. And to make things worse, I think mkpatches doesn't preserve the names of the patches when it regenerates them. (Or if it does, then this is some developer's "fault" ;-)

Could we make it a "policy" to add a comment on top of each patch stating its purpose and "feedback status" (i.e. if it has been sent upstream or not, who is responsible for the process, where it is being tracked, etc.)?

Julio M. Merino Vidal <>

Home | Main Index | Thread Index | Old Index