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

[Randall Wood]

On 22 Oct 2007, at 18:26, Ryan Schmidt wrote:

> 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.

I have one concern about this: how do we which order patch files will  
be applied against a given file? I can see where a diff's 3 lines of  
context overlap another diff's modifications, and if applied in the  
wrong order, can cause problems...

>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev



Randall Wood
rhwood at mac.com
http://shyramblings.blogspot.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."