Ports and their dependencies

[Ryan Schmidt]

On Jun 9, 2008, at 11:17, Tabitha McNerney wrote:

>> The man page says what lib,bin,path mean:
>>
>> > type:<filename>:<port>
>> >
>> >      may be used. Where type is "bin" if <filename> is a  
>> program, "lib"
>> >      if it is a library, or "path" if it is a path to an  
>> installed file.
>
> Reading this and also the previous posts, the condition of "path"  
> being a path to an "installed file" (and given Ryan's example in a  
> different thread whereby the php5 port with the mysql5 variant  
> added triggers the depends_lib of a path whose path value leads to  
> a possibly installed configuration file (but this configuration  
> file only exists if the mysql5_dev port has been installed)

I didn't say that: the situation is that either the mysql5 port or  
the mysql5-devel port can provide the mysql_config5 file (and indeed  
all the MySQL libraries) but only one of these two ports can be  
installed at a time. This is (or should be) the case for all -devel  
ports. The intention is that most users will use mysql5 but some will  
want to try the new features only available in mysql5-devel. To  
support this notion, all ports that depend on MySQL 5 functionality  
must declare their dependency on MySQL 5 not via a port:-style  
dependency (because that would unequivocally require the mysql5 port,  
not the mysql5-devel port), but instead via a path:-style dependency  
to a specific path within ${prefix}. The lib:-style dependency should  
not be used, because a MySQL library provided by the operating system  
(for example on Mac OS X Server) would also satisfy that dependency,  
but we don't want it to.

Maybe path:${prefix}/something:portname should be the preferred  
dependency style (instead of port:portname)? Unless we have a better  
plan for -devel ports (or the "slots" feature) in the future.

> kind of strikes me as a means to confusion because such a  
> dependency isn't really a "non-port" then right?

I too find the "non-port" terminology confusing and not entirely  
accurate.

> In other words, an "installed file" which has a path that only  
> exists if the port responsible for installing that file has itself  
> been built and installed, then really that's not a "non-port"  
> unlike a lib: or bin: which could be, say, an Apple Mac OS X  
> provided resource (library or binary). True? Granted, from a pure  
> syntactical standpoint, the "path: ..." is not the same as a  
> "port: ..." and thus I can see why its categorized as a "non-port".