Questions on dependencies

Daniel J. Luke dluke at geeklair.net
Fri Nov 1 13:09:18 PDT 2013


On Nov 1, 2013, at 4:04 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Nov 1, 2013, at 15:02, Daniel J. Luke <dluke at geeklair.net> wrote:
>> On Nov 1, 2013, at 3:58 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> On Nov 1, 2013, at 14:55, Daniel J. Luke <dluke at geeklair.net> wrote:
>>>> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>>> On Nov 1, 2013, at 14:44, Daniel J. Luke wrote:
>>>>>> On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote:
>>>>>>> The solution would be for ports that use the ImageMagick libraries to depend on it via depends_lib and for those only needing its programs to depend on it via depends_build and/or depends_run.
>>>>>> 
>>>>>> I don't think you can say depends_run means 'only depends on programs' unless we specifically define it to mean that (I can think of a case where something doesn't link with a library or plugin, but loads it at runtime).
>>>>> 
>>>>> I didn’t say that. I said perhaps we should make “depends_lib” mean that it depends on (i.e. links with) a library. That doesn’t seem so unreasonable.
>>>> 
>>>> the quoted sentence indicates:
>>>> 
>>>> 1. depends_lib == linked to it (needs revbump)
>>>> 2. depends_build/depends_run == only needs its programs.
>>>> 
>>>> I'm saying that unless we define depends_build/depends_run as only pertaining to programs, that 2 isn't necessarily true (an application can have a runtime dependency on a library or plugin that it loads at runtime but isn't linked with).
>>> 
>>> Sorry if I was unclear. My only proposal is:
>>> 
>>> depends_lib should mean that a port links with another port’s library, such that it needs a revbump if that port’s library version increases
>>> 
>>> If you link with another port’s library, use depends_lib
>>> 
>>> If you do not link with another port’s library, do not use depends_lib
>> 
>> ok, so you don't actually want to fix the problem you have with some things depending on ImageMagic libraries and some things depending on just the programs? :)
> 
> The way I want to fix it is to go through the ports that depend on ImageMagick, find those that declare “depends_lib port:ImageMagick” but only use its programs, and change them to “depends_run port:ImageMagick” (presuming they use the programs at runtime) and if they check for the presence of the program at configure time, then also add “depends_build port:ImageMagick”.

which again, you're assuming that no port has a runtime dependency on a library that doesn't link with that library (which a reasonable person might express as a  depends_run dependency). This is #2 from above.

The only way you can assume that depends_run means "only depends on programs" is if we define depends_run to mean "only depends on programs".

In other words, for this to work, depends_lib doesn't just mean "I link to a library provided by this port" but "I link to, or load a library or plugin provided by this port."

I don't think it's a /bad/ idea to define things that way, just that it needs to be clear so that maintainers use depends_lib/depends_run in a way that is consistent.

> The part of the question I was replying to was "is there any difference between listing a package in both depends_build and depends_run compared to just listing it in depends_lib”. I was trying to explain what I thought the difference should be.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+





More information about the macports-dev mailing list