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. Addingorder means that you can't just add the change and diff again, you have
to consider whether you should modify one of the existing patchfragments 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 <jmmv84%gmail.com@localhost>