portmaster is not always recursive

[Doug Barton]

On Sun, 30 Aug 2009, Miroslav Lachman wrote:

> Doug Barton wrote:
>> Ok, I found the problem, but the bad news is that I don't know what the 
>> solution is going to be. I've cc'ed ale since what I'm seeing is weird 
>> behavior by the php5-mcrypt slave port.
>> 
>> What portmaster does by default when looking for dependencies is to run 
>> 'make build-depends-list run-depends-list | sort -u' to get the list of 
>> things to check. I used to just do all-depends-list by default but users 
>> complained that it was creating problems by recursing so far down the tree.
>
> Does it mean that portmaster checks only first level dependencies unless -t 
> is given? (Maybe it is good behavior, I am just asking it to be sure that I 
> understand it well)

That's not exactly right, but it's about 90% right so close enough. :) The 
discrepancy relates to how individual ports report their dependencies, but 
for almost all purposes that is correct, yes.

> real world example:
> If I do `portmaster amavisd-new-2.6.4_1,1` and there will be available update 
> for archivers/p5-Compress-Raw-Bzip2 but not for dependencies between, it will 
> not be updated, because it is too deep?

Assuming that the latter is not listed as a dependency by amavisd-new, 
then no, it will not be updated that way.

> I don't know the exact definition of "slave port", but can it be that there 
> are 2 types of slave ports?
> Where one type is for example proftpd-mysql, which conflicts with master port 
> proftpd (only one of them can be installed)
> The second type is php5-mcrypt, which is only extension for master port and 
> cannot be installed alone?

I suspect that you are correct here, but I do not claim comprehensive 
knowledge of slave ports. :)  I will add that there is at least one more 
type, e.g., editors/pico-alpine and mail/alpine where the former is a 
slave of the latter because it uses the same distfiles, same basic 
OPTIONS, etc; although they install totally different programs.

>> Miroslav, for your specific problem you can add the -t option to portmaster 
>> to force it to do all-depends-list, which will cause portmaster to "see" 
>> the apache dependency. Other than that I'm not sure how to proceed. I 
>> suppose that I could force all-depends-list if MASTERDIR is set in a 
>> Makefile, but I'm kind of hesitant to do that unless it becomes obvious 
>> that the problem is more widespread.
>> 
>> 
>> hope this helps,
>
> Yes, it really helps. Now I know my favorite ports mgmt tool better then 
> before and as more I think about {build|run}-depends-list versus 
> all-depends-list it seems that current behavior is better. And if someone 
> wants all-depends-list, there is -t options. So all is fine.

FWIW, there is always the -a option to update everything that needs it.

> Maybe this difference can be explained in portmasters manual. (stating that 
> normally {build|run}-depends-list is used and only first level of 
> dependencies are checked/updated and if someone wants really recursive check, 
> the -t option must be used)

I get two complaints about the manual. The first is that it does not cover 
enough of the details, the second is that it's too long. I don't know how 
to make both groups happy. :)  I will think about adding something to the 
man page about this though.

I should also point out that -t does not mean "really recursive check." 
Portmaster is always recursive, the difference is not necessarily how deep 
it goes, it can also be how "wide" it goes as well.

> So the last thought is some new option for portmaster to force reinstall of 
> all intermediate dependencies between A and E, even if there are no updates 
> for them.

The -f option already does this.

> Thank you again for you explanation of the problem. It is really educational 
> to me.

Glad to help.

Doug

-- 

     This .signature sanitized for your protection