Le 21 oct. 07 à 20:15, source_changes@macosforge.org a écrit :
Revision 30149 Author rhwood@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 -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Oct 21, 2007, at 13:38, N_Ox wrote:
Le 21 oct. 07 à 20:15, source_changes@macosforge.org a écrit :
Revision 30149 Author rhwood@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.
Le 21 oct. 07 à 23:28, Ryan Schmidt a écrit :
On Oct 21, 2007, at 13:38, N_Ox wrote:
Le 21 oct. 07 à 20:15, source_changes@macosforge.org a écrit :
Revision 30149 Author rhwood@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.
Understood! I agree with you, we should name them with .diff extension. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Ryan Schmidt wrote:
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.
Having one such patch file for each affected source file is the BSD ports convention: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow- patch.html The MacPorts ones named as patch-whatever.diff can affect more than one source file.
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.
Last thing I heard, both styles of patches were allowed in the MacPorts Portfiles. Outside of ports, it's common to have files named as foo-1.0-bar.patch, which is a patch for fixing "bar" in version 1.0 of "foo" - usually applied as patch -p1. --anders
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@macosforge.org a écrit :
Revision 30149 Author rhwood@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. Regards,... -jmpp
Juan Manuel Palacios wrote:
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.
This is what we currently have, except for this new mandatory .diff suffix (that breaks Ports compatibility) --anders
On Oct 22, 2007, at 3:25 AM, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
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.
This is what we currently have, except for this new mandatory .diff suffix (that breaks Ports compatibility)
You mean FreeBSD Ports? And, how do we break compatibility? Solely with naming conventions?I wouldn't worry too much about that, as a simple mv(1) is all that's needed to comply ;-) Or is there something else that I'm not seeing? Regards,... -jmpp
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@macosforge.org a écrit :
Revision 30149 Author rhwood@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.
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@macosforge.org a écrit :
Revision 30149 Author rhwood@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@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."
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...
I've always assumed that the order in which they are applied is the order in which they are listed in the Portfile (which would seem logical to me: the maintainer decides the order), but I guess this makes a pretty good test case to study ;-) Hint, hint! Regards,... -jmpp
Juan Manuel Palacios wrote:
This is what we currently have, except for this new mandatory .diff suffix (that breaks Ports compatibility)
You mean FreeBSD Ports? And, how do we break compatibility? Solely with naming conventions?I wouldn't worry too much about that, as a simple mv(1) is all that's needed to comply ;-) Or is there something else that I'm not seeing?
That's it, that's all. "README ? Who would know that it's a readable file, README.txt it is. Makefile ? sheesh, Makefile.mak. And what's this ? A program ? .exe !" File suffixes suck... --anders
On Oct 23, 2007, at 01:09, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
This is what we currently have, except for this new mandatory .diff suffix (that breaks Ports compatibility)
You mean FreeBSD Ports? And, how do we break compatibility? Solely with naming conventions?I wouldn't worry too much about that, as a simple mv(1) is all that's needed to comply ;-) Or is there something else that I'm not seeing?
That's it, that's all.
"README ? Who would know that it's a readable file, README.txt it is. Makefile ? sheesh, Makefile.mak. And what's this ? A program ? .exe !"
File suffixes suck...
File suffixes are useful because they enable you to associate files with applications by file extension. When I doubleclick a file called "README" on my Mac it opens into TextEdit. I hate TextEdit and do not wish to use it, but because the filename has no extension, I cannot inform the OS that I would like it to open into TextWrangler instead. Same with files named Portfile or Makefile or whatever else.
Ryan Schmidt wrote:
File suffixes suck...
File suffixes are useful because they enable you to associate files with applications by file extension. When I doubleclick a file called "README" on my Mac it opens into TextEdit. I hate TextEdit and do not wish to use it, but because the filename has no extension, I cannot inform the OS that I would like it to open into TextWrangler instead. Same with files named Portfile or Makefile or whatever else.
I'm sure it could be set up to accept "foo.port" in addition to "Portfile". (so that you could associate the .port extension with your favorite editor) But maybe it should rather be a bundle, with all the other files needed too ? Then again, there's already the ".portpkg" for a port with all needed files... --anders http://svn.macports.org/repository/macports/users/jberry/mpwa/doc/ portpkg-design.txt
participants (5)
-
Anders F Björklund
-
Juan Manuel Palacios
-
N_Ox
-
Randall Wood
-
Ryan Schmidt