On Jan 12, 2007, at 12:00 AM, Michael Sternberg wrote:

The netcdf port seems orphaned:

http://trac.macports.org/projects/macports/browser/trunk/dports/science/netcdf/Portfile

As per http://metadir.andrew.cmu.edu/mailsearch.html the previous maintainer is no longer affiliated with CMU. I'll see if I can follow up more tomorrow.

The reason I'm asking is because I need the fortran interface for a user's code, and perhaps later plug in more recent versions. I managed to locally add a variant "+ifort" using "port edit", which relies on the Intel Fortran compiler, and the package's regression test "make test" passes, explicitly verifying the fortran interface as well.

Great. Perhaps you'd like to become the maintainer of the port?

Now for the bleeding newbie questions:

Q1: Is it OK to use a commercial compiler?

I have no idea if there's a general policy on that. By use do you mean the compiler's used to install the port, or the installed port utilizes the compiler? If it's the former, I'd say try and use an open-source compiler for which a Portfile exists (gcc41 includes fortran95 support, for example). If it's the latter, it's probably ok but someone else really should chime in here.

Q2: What's the canonical way to express that?

- note dependency (if any)?

- note compiler version? (ifc7, ifc8, and ifort9 are notably different)

If you depend on a compiler for which the Portfile exists, declare the dependency like you see other ports doing. If you require a commercial compiler to install the port, well, I don't know what you should do. Offhand I'd say note such in the long_description. Perhaps if this is something that's necessary we could add, for example, a variant on the bin: style of dependency which takes just a binary name (i.e. no port name), and if the binary isn't found it errors out?

If your port doesn't require the compiler to build, and functions normally if the compiler is not present (but utilizes the compiler if it is), I'd say just note that in long_description. Of course, this is only if the compiler has no Portfile (which a commercial one wouldn't). Again, if there is a Portfile, you should do a depends_run on it.

Q3: Where do I submit a patch to a non-maintainer? If I go to:

http://trac.macports.org/projects/macports/report

and click on the big "New Ticket" (not obvious as a link, BTW), I get:

http://trac.macports.org/projects/macports/newticket

Permission Denied

TICKET_CREATE privileges are required to perform this operation

You should be able to register for an account. Look in the upper-right corner of the page. I've heard of people saying they still can't create tickets after registering, but hopefully that's been fixed. If not, simply speak up and a Trac maintainer should be able to give you appropriate privileges.

Has the dust settled since the DarwinPorts migration? Seems some of the docs are not yet migrated.

Not entirely.

Any help appreciated - I mean, I'd like to push my patch upstream, so I get the benefit on other hosts without creating my own patch management system ;-)