[84842] trunk/dports/databases

[Ryan Schmidt]

On Oct 4, 2011, at 02:02, Titus von Boxberg wrote:
> Am 03.10.2011 um 23:38 schrieb Ryan Schmidt:
>>> +    configure.args-append       -DMYSQL_LIBRARY=/opt/local/lib/mysql5/mysql/libmysqlclient_r.dylib
>>> +}
>> 
>> Don't hardcode /opt/local; use ${prefix}.
> Yes, sigh…
> Since that accounts for an considerable share of your QA mails, what about that change:
> 
> --- share/macports/Tcl/port1.0/portlint.tcl.org	2011-10-04 08:49:31.000000000 +0200
> +++ share/macports/Tcl/port1.0/portlint.tcl	2011-10-04 08:54:03.000000000 +0200
> @@ -249,6 +249,11 @@
>             }
>         }
> 
> +        if {[string match "*/opt/local*" $line]} {
> +            ui_error "Do not hardcode /opt/local, use \${prefix} instead!"
> +            incr errors
> +        }
> +	
>         if {[regexp {(^|\s)configure\s+\{\s*\}} $line]} {
>             ui_warn "Line $lineno should say \"use_configure no\" instead of declaring an empty configure phase"
>             incr warnings

Well that would give both false positives and false negatives.

There are a handful of ports that are using the string /opt/local in an ok manner. It would give false positives for ports like lua-glut that say:

post-patch {
	reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/Makefile
}

Sometimes the developers of software try to be helpful and actually code /opt/local (or /sw) into their build scripts, which we then have to remove, or replace with the real ${prefix} as above. In the case of lua-glut though it's just a poorly-written patch that can be improved to no longer include the string /opt/local; I'll fix that one momentarily.

It would give false negatives for ports that hardcode /opt/local in their patchfiles.

Personally I just have a rule set up in my mail program that flags commit messages containing /opt/local. Then I can inspect them and see if the use of /opt/local is problematic, and if so point it out or fix it.


>>> 
>>> +        configure.args-append       -DSQLITE3_LIBRARY=/usr/lib/libsqlite3.dylib
>>> +    }
>>> +}
>> 
>> With SQLite on the other hand there isn't a database server. It's just a set of libraries. As such I see no reason to allow the user to use the almost certainly older version OSX provides. Just let the user use the version in MacPorts as per our usual policy of using only MacPorts libraries.
> I thought that during the recent heated discussion about too many ports depending on too much other ports
> there was an agreement that OSX libraries might be used, though that possibility not being endorsed.

My recollection is that Jordan suggested it, I opposed it and presented a number of scenarios we've encountered before about why it's still not a good idea, and no further consensus was reached. Which is to say we should remain with our current strategy of not using OSX libraries.

We've had some leniency for integrating with some OSX versions of web and database servers, like apache and mysql, so that users can use Apple's OSX Server GUIs for managing them. That is to say, there are years-old outstanding requests to allow php5 to integrate with Apple's versions of apache2 and mysql5, which I'm not opposed to, but have not felt the urgency to implement, and there has not been any further demand for this expressed.

As I recall the recent discussion began when someone questioned an unnecessary dependency on the gmake port. We have always made the exception before for things like gmake that are part of the compilation / build system, just as we make use of Xcode's compilers and don't attempt to force the use of a MacPorts compiler.