tech-pkg archive

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

Re: patch filenames

On 07/01/2008, at 18:41, Aleksey Cheusov wrote:

I disagree, having designed and used a packaging system
which used this infrastructure. It works very well, is
kind to the SCM, and is efficient to the point of brevity.

I regulary have to deal with files that are patched already. Adding
order means that you can't just add the change and diff again, you have
to consider whether you should modify one of the existing patch
fragments in which case you have to regen all later patches. We do *not*
have the tools for this.

On the contrary, this approach works very well in practice.

There are now tools to manage this sort of thing.  Even when there
aren't, all that is necessary is to delete the old patch, and append
the new one on the end.

I would say, that this approach ("append at the end") is easier
to understand and easier to apply.  It is easier to explain too,
thus it should be expected to be less error-prone.

I'm not pkgsrc developer and nobody counts my vote but I agree with
Joerg. IMHO current scheme is easier and less error prone, doesn't
lead to patch rejects etc. etc. In order to send patches to the
upstream author all patches should be catted together and then
pkgsrc-specific part should be removed from it. I don't see any
problem here. This easy operation is made not very often because not
all patches can be sent to upstream.

It is not as easy as you make it sound. Many, many times, putting all the patches together and removing pkgsrc-specific bits will result in a patch that will NOT be accepted by upstream. The reason: the patch will contain fixes and/or improvements for many different, unrelated stuff.

Upstream wants patches that are self-contained and do *just one* conceptual thing (not necessarily touching just one file). You then need to submit each of these patches as an independent bug report, with a correct explanation of the problem and why your solution is appropriate.

Julio M. Merino Vidal <>

Home | Main Index | Thread Index | Old Index