New and update math/science ports
Hello, I am new to MacPorts and would like to contribute new and update ports mainly in math and science. I have some comments on MacPorts homepage. I find the home page unfriendly to newbies. They have to find clicking "wiki." Although I understand that WordPress is used so news are shown, a page for the first step is needed. I had hard time finding that how to contribute until I find "Trac." 1. You have to register. 2. You have to know what Trac is. 3. You have to find the attachment appears on the next page to the new ticket page. For give me for full of complains. In fact I find MacPorts useful and I would like to switch to MacPorts and contribute several math/ science packages. List of my tickets. * infrastructure: g95-0.90: 11511 odcctools 20060608 (required for g95-0.90): 11512 netcdf-3.6.1 (an update): 11513 libdap-3.7.5: 11514 libnc-dap-3.7.0: 11515 cdo-1.0.6: 11516 nco-3.1.8: 11517 mpich2-1.0.5p3 (an update): 11525 * script languages for math/science: octave-2.9.9 (an update): 11518 octave-forge (an update, g95 variant): 11519 gdl-0.9pre4: 11524 * plotting package: plplot-5.7.2 (for gdl): 11522 freetype-2.3.1 (required by plplot): 11520 freefont-ttf (required by plplot): 11521 gsl-1.9 (an update): 11523 - Components for 11519 and 11512 should have been ports. - Types for 11513, 11514, 11515, 11525 should have been enhancement. - In fact I don't now which to choose from those menus well. - It is not clear to me your policy how to set dependencies (old doc incomplete). - Do dependencies need a version number? How can I set it? Best wishes, Takeshi
On Mar 10, 2007, at 9:03 AM, Takeshi Enomoto wrote:
I am new to MacPorts and would like to contribute new and update ports mainly in math and science.
Welcome!
I have some comments on MacPorts homepage. I find the home page unfriendly to newbies. They have to find clicking "wiki." Although I understand that WordPress is used so news are shown, a page for the first step is needed.
I think we all agree that the website could use some love. The old darwinports site was reasonable, but since we've moved to MacOSForge nobody's taken the time to really make the site all that accessible. I believe the people with the capability to do so are simply busy, though that's just a guess.
I had hard time finding that how to contribute until I find "Trac." 1. You have to register. 2. You have to know what Trac is. 3. You have to find the attachment appears on the next page to the new ticket page.
For give me for full of complains. In fact I find MacPorts useful and I would like to switch to MacPorts and contribute several math/ science packages.
List of my tickets.
* infrastructure:
g95-0.90: 11511 odcctools 20060608 (required for g95-0.90): 11512 netcdf-3.6.1 (an update): 11513 libdap-3.7.5: 11514 libnc-dap-3.7.0: 11515 cdo-1.0.6: 11516 nco-3.1.8: 11517 mpich2-1.0.5p3 (an update): 11525
The ones which are updates to existing ports, have you emailed the maintainer of said port? The way MacPorts works is the maintainer is responsible for a port, and nobody else should update the port without permission. If you email the maintainer and haven't heard back in 72 hours, then other people can commit changes to the port. So for the ones which are updates, I recommend emailing the maintainer of those ports now, and if you hear nothing in 3 days, email the list about those ports and say that you haven't heard anything in 3 days
* script languages for math/science:
octave-2.9.9 (an update): 11518 octave-forge (an update, g95 variant): 11519 gdl-0.9pre4: 11524
* plotting package:
plplot-5.7.2 (for gdl): 11522 freetype-2.3.1 (required by plplot): 11520 freefont-ttf (required by plplot): 11521 gsl-1.9 (an update): 11523
- Components for 11519 and 11512 should have been ports.
Ok, component changed.
- Types for 11513, 11514, 11515, 11525 should have been enhancement.
Ok, types changed. There are other ticket,s like 11519, which are still defect. Should those remain defect?
- In fact I don't now which to choose from those menus well.
New/updated ports should be type enhancement, component ports. Revisions to existing ports (revisions meaning changing the portfile without bumping the version, often incrementing the revision number if the build products will change) should be defect if it's fixing a bug or enhancement if it's adding something like, say, a variant.
- It is not clear to me your policy how to set dependencies (old doc incomplete). - Do dependencies need a version number? How can I set it?
Dependencies are unversioned. Since MacPorts only knows how to install the current version of a port, the dependency can't specify an older (or newer) one as it would be unable to be fulfilled. The manpage for portfile.7 talks about how to specify dependencies, though I disagree with how it presents port:foo versus bin:foo:bar (or lib:libfoo:foo). I believe you should use bin: or lib: if those accurately describe the type of dependency - need libjpeg? use a lib:libjpeg:jpeg dependency. Need gnumake? Use bin:gnumake:gmake. Doesn't matter if apple can or does satisfy these dependencies. The port:foo variation, I think, should generally only be used if you don't know how the dependency is meant to be satisfied (e.g. what library? what binary? etc.) or if you require a version newer than you know apple provides. HTH, Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Mar 10, 2007, at 12:20 PM, Kevin Ballard wrote:
The manpage for portfile.7 talks about how to specify dependencies, though I disagree with how it presents port:foo versus bin:foo:bar (or lib:libfoo:foo).
You might disagree, but the port:foo version is preferred as a matter of policy (and because it prevents a certain class of problems).
I believe you should use bin: or lib: if those accurately describe the type of dependency - need libjpeg? use a lib:libjpeg:jpeg dependency. Need gnumake? Use bin:gnumake:gmake. Doesn't matter if apple can or does satisfy these dependencies.
It makes sense to use those styles if you can be sure that anyone satisfying the conditions they impose is OK (this is not usually the case since they just look for a file and the test cannot make sure the file is actually one that is OK). They're a good alternative if you want a version of python installed, but don't actually care which version it is (for example, how the subversion-pythonbindings port works).
The port:foo variation, I think, should generally only be used if you don't know how the dependency is meant to be satisfied (e.g. what library? what binary? etc.) or if you require a version newer than you know apple provides.
port:foo version should be used unless there is a good reason (tm) for not using it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Hello Kevin and Dan, Thank you for your replies.
Welcome!
I am glad to hear this.
I think we all agree that the website could use some love.
I will write what I learnt from you in my blog in Japanese.
The ones which are updates to existing ports, have you emailed the maintainer of said port?
I did as you suggested. What about those ports written by nomaintainer@macports.org?
Revisions to existing ports (revisions meaning changing the portfile without bumping the version, often incrementing the revision number if the build products will change) should be defect if it's fixing a bug or enhancement if it's adding something like, say, a variant.
Then could you change as follows? #11519 octave-forge enhancement #11512 odcctools enhancement #11516 cdo-1.0.6 enhancement Please set priorities of octave-forge and odcctools to Nice to have.
Dependencies are unversioned.
I like this simplicity.
You might disagree, but the port:foo version is preferred as a matter of policy (and because it prevents a certain class of problems).
I prefer port:foo to what Fink does. In Fink I had to divide one into binary, libraries and headers. Could someone tell me how portfiles are reviewed? Will someone commit it if it is OK? Takeshi
On Mar 11, 2007, at 10:03 AM, Takeshi Enomoto wrote:
The ones which are updates to existing ports, have you emailed the maintainer of said port?
I did as you suggested. What about those ports written by nomaintainer@macports.org?
Those are free game for anybody to commit to (and, ideally, take over maintainership).
Then could you change as follows?
#11519 octave-forge enhancement #11512 odcctools enhancement #11516 cdo-1.0.6 enhancement
Please set priorities of octave-forge and odcctools to Nice to have.
Done
Could someone tell me how portfiles are reviewed? Will someone commit it if it is OK?
In general the best way to do this is to submit tickets, and email the maintainer about them. If the maintainer doesn't respond in 3 days, or if there is no maintainer, email this list with the tickets (be sure to state the maintainer didn't respond after 3 days if that's the case).. Generally somebody looks at the tickets and commits them if they're fine, or tells you what's wrong if they aren't. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
participants (3)
-
Daniel J. Luke
-
Kevin Ballard
-
Takeshi Enomoto