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

[Tabitha McNerney]

Ryan and Josh and everyone else,

Thank you so very very much for helping to clarify how all this works and
disambiguating the terminology and helping to understand how it all lays
together logically!

We could write a book: "The Anatomy of MacPorts" and make it a Best Seller
on Amazon! All jokes aside, would it be helpful to take the great
explanations you have all written and integrating them into chapter 5.4.1 of
the MacPorts Guide
<http://guide.macports.org/#reference.dependencies.types>? Is this
something that would benefit the MacPorts Community (even though I
might have been one of the first people to ask such questions explicitly)?

Thanks,

T.M.

On 6/8/08, Joshua Root <jmr at macports.org> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20080608/45aac577/attachment.htm