Ports and their dependencies (run deps and also versioning questions)

[Ryan Schmidt]

On Jun 8, 2008, at 05:50, Tabitha McNerney wrote:

> Hi, I have a followup question. I noticed that with the subversion  
> port, when I get information from it (along with enabling its  
> variant, the perl variant), for the lib_depends output, I get:
>
> $ port info --depends_lib postgresql81 @8.1.11 +perl
>
> -->
>
> depends_lib: port:readline, port:openssl, port:zlib, bin:perl:perl5.8
>
> So if I follow Josh's logic, what this means is that there is a  
> library dependency of a non-port type that has an executable  
> condition which is saying, in a paraphrase:
>
> "the port installation of subversion plus its perl variant has  
> library MacPort dependencies of readline, openssl and zlib' and it  
> has a non-MacPort dependency baed on the perl binary executable. If  
> this perl executable is available on the operating system (e.g.,  
> Mac OS X) then use it, but if this perl executable can not be  
> found, then the MacPort perl5.8 should be installed and once its  
> installed its binary executable shall be used" ??

That's about right, except that I would say "If the perl executable  
is available on the OS, then consider the dependency satisfied,  
otherwise install the perl5.8 port."


> Is it not unusual to see binary executable types of non-port  
> dependencies in the library (depends_lib) definition of a port? It  
> doesn't matter if binary requirements are in fact mixed and matched  
> (regardless of dependency type, library, build, run)?

Is your question why is a *binary* (executable) appearing in a  
*library* dependency clause? That's not necessarily wrong. For  
example, in the php5 port's mysql5 variant, I declare the dependency  
like this:

depends_lib-append path:${prefix}/bin/mysql_config5:mysql5

The MySQL 5 software doesn't link with the mysql_config5 program as a  
library, sure, but it does use the mysql_config5 program at build  
time to figure out where the includes and libraries are, and then it  
links with those libraries. The point in any of the non-port  
dependency declarations is to identify a single representative file,  
the presence or absence of which indicates whether the indicated port  
needs to be installed to satisfy the dependency or not. In the case  
of php5 +mysql5, I declared it this way so that if the user already  
has mysql5-devel installed, that will satisfy the dependency. In the  
case of postgresql81, the dependency may have been written the way it  
was so that if the user already has perl5.10 installed, that would  
satisfy the dependency. Actually I think many ports declare their  
perl dependency like this so as to avoid forcing the user to install  
perl5.8, which is a rather large port, when Mac OS X's included perl  
could probably handle the task. For basic perl tasks, perl hasn't  
changed in a long time.

I don't know what postgresql81 actually does with perl. If something  
installed by the postgresql81 port actually links with one of the  
libraries installed by the perl port in ${prefix}/lib/perl5/5.8.8/ 
darwin-2level/auto then a library dependency (depends_lib) is fine.  
But if OTOH something installed by the postgresql81 port merely makes  
use of the perl executable at runtime, then a runtime dependency  
(depends_run) would be more appropriate. Or, if the perl executable  
is just used during the build process to produce something, and then  
perl is not needed anymore to run the thing, then a build-time  
dependency (depends_build) would be correct (see curl-ca-bundle for  
an example). To discover what it should be, we'd have to consult the  
PostgreSQL source code or ask the maintainers of the postgresql81  
port or the authors of the PostgreSQL software.