[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
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
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
IMO we must reduce the number of patches. Often it is not clear why
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
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 <jmmv84%gmail.com@localhost>
Main Index |
Thread Index |