[30149] trunk/dports/gnome/gnome-doc-utils

[Ryan Schmidt]

On Oct 22, 2007, at 02:12, Juan Manuel Palacios wrote:

> On Oct 21, 2007, at 5:28 PM, Ryan Schmidt wrote:
>
>> On Oct 21, 2007, at 13:38, N_Ox wrote:
>>
>>> Le 21 oct. 07 à 20:15, source_changes at macosforge.org a écrit :
>>>
>>>> Revision 30149 Author rhwood at macports.org Date 2007-10-21  
>>>> 11:15:29 -0700 (Sun, 21 Oct 2007) Log MessageAdd a patch to  
>>>> xml2po that, against all reason, seems to work. Bump the  
>>>> revision number so everyone gets it.
>>>
>>> Shouldn't the patch be renamed "patch-xml2po_xml2po.py"?
>>> http://geeklair.net/new_macports_guide/#development.patches.source
>>
>> It should be called "patch-xml2po_xml2po.py.diff". The guide  
>> should be updated to recommend this style.
>>
>> I object to naming patchfiles with the original file's extension.  
>> The file "patch-xml2po_xml2po.py" is *NOT* a Python file! It is a  
>> difference of two Python files. Editors attempting to perform  
>> source code highlighting based on the file extension will do so  
>> incorrectly for files which are in fact diffs. Call the file what  
>> it is. Put ".diff" at the end.
>>
>> The old guide was contradictory, as it recommended one way in one  
>> place and the other way in another place. Let's please standardize  
>> on the format "patch-FOO.diff". According to "find . -name 'patch- 
>> *.diff' | wc -l" we already have hundreds of patchfiles following  
>> this convention.
>
> 	I support advertising this format as the "recommended" one for  
> patchfiles, absolutely! (and not "<something>.patch" since the  
> "patch-<something>.diff" format already conveys both the "patch"  
> and "diff" messages -- two birds with one stone, as we say  
> here ;-). But why do I say "recommended"? 'Cause obviously Portfile  
> writers are gonna come asking why we demand something in our guide  
> and yet other naming styles exist in our ports tree... 'cause it  
> just aint true that we're gonna rename all patchfiles that don't  
> follow the convention and adapt the corresponding Portfiles to work  
> with the new names.
>
> 	So lets make this format our "official advice", but I would  
> refrain from *demanding* it just yet.
>
> 	And with respect to patchfile reach, I still favor and support the  
> "one patchfile per fix" convention, meaning a single patchfile can  
> touch as many source files as it takes to fix a particular problem  
> if need be, no need to make separate patchfiles for each source  
> file if it's the same problem. Different fixes of course *must* go  
> in different patchfiles. Based on this, the <something> part in the  
> "patch-<something>.diff" format can either stand for the name of  
> the file we're patching (including its extension), if we're  
> patching a single file (e.g. patch-main.c.diff), or a string  
> hinting the problem we're fixing with the patch (e.g. patch- 
> darwin_defines.diff), in case we touch multiple files. These  
> guidelines immediately lead to a clash in case a single file needs  
> fixes for multiple, logically different problems, however; in this  
> case I'd say it's OK to have "patch-problem1.diff" and "patch- 
> problem2.diff" patchfiles for this sole hypothetically problematic  
> source file.

Sure, there are no demands, just recommendations. :) nox has already  
updated "port lint" to complain about portfiles that don't match the  
recommendation. So as people run "port lint" on their portfiles,  
hopefully they will be encouraged to fix the names of their patchfiles.

IIRC, the old guide did recommend one patch file per source file  
being patched, but I fully support your recommendation of one patch  
file per issue being fixed. Let's get that in the guide too, if it's  
not there already.