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

[Joshua Root]

Tabitha McNerney wrote:
> On 6/6/08, *Joshua Root* <jmr at macports.org <mailto:jmr at macports.org>> wrote:
>     Tabitha McNerney wrote:
> 
>         But, then my script ran into this specific problem:
> 
>         $ port info --depends_lib speex @1.0.5
> 
>         -->
> 
>         depends_lib: lib:libogg:libogg
> 
>         Hmmm ... the repeat of the library dependency libogg looks to be
>         incorrect.
>         Also, the first instance of the libogg dependency is preceded by
>         "lib:" but
>         shouldn't that be "port:" instead?
> 
> 
>     This is not an error, but a different type of dependency. A
>     "port:foo" dependency means "install the port named 'foo'", whereas
>     "lib:foo:bar" means "check if the library 'foo' is present, and if
>     not, install the port named 'bar'". You can also use 'bin' or 'path'
>     instead of 'lib' to make the port installation conditional on the
>     absence of executables and arbitrary files, respectively.
> 
> 
> 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 right (though the last part, "once its installed its binary 
executable shall be used," is an implicit consequence rather than a 
guarantee made by the dependency).

> 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)?

Depends_lib doesn't apply to only libraries. Its actual meaning is 
"these dependencies are required both at build time and at runtime." 
Depends_build means "required at build time but not runtime", and 
depends_run means "required at runtime but not build time." So all 
dependency specifications (bin,lib,path,port) are valid in each list 
(depends_lib,depends_build,depends_run). (Do we have preferred 
disambiguating terminology for these concepts? Would make discussing 
them a lot clearer...)

As I mentioned in the earlier discussion of gperf, MacPorts didn't 
always have port: dependencies, so there are probably quite a few of the 
other kinds left around which should really be changed to port:. Often 
they don't cause any problems; sometimes, as with gperf, they do.

Apart from XFree86, a deliberate one that you'll see a lot is 
bin:tex:texlive. This is because there are multiple TeX distribution 
ports, which are quite large, and many ports will work with any of them 
equally well.

- Josh