Re: patch filenames

[George Georgalis <george%galis.org@localhost>]

On Mon, Jan 07, 2008 at 09:22:20PM +0100, Julio M. Merino Vidal wrote:
> 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.

since the existing doc doesn't say *must* why not
just use the most appropriate method for the package
issue in question. I like the idea of giving patches a
relevant name but why require all packages to use a
unified patch file vs a mix as appropriate. eg 

_NetBSD_.patch might patch 60% of the files which require it
pr65335.patch might patch files relevant to the PR
include.patch might fix the include file

no matter how it's done (as one file or not) patch
install ordering is important (sorry, I don't know
the existing patch ordering method to comment on it)
but if patches are named according to their purpose
the work of producing a single upstream patch (eg
less other patches pkgsrc normally does first), from
the pkgsrc tree, should be easiest, I expect.

// George

-- 
George Georgalis, information system scientist <IXOYE><