From owner-freebsd-ports@FreeBSD.ORG Sun Aug 30 20:02:51 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60BD7106566B; Sun, 30 Aug 2009 20:02:51 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id DD22E8FC13; Sun, 30 Aug 2009 20:02:50 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C318019E044; Sun, 30 Aug 2009 22:02:46 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9B86C19E043; Sun, 30 Aug 2009 22:02:44 +0200 (CEST) Message-ID: <4A9ADAE6.70506@quip.cz> Date: Sun, 30 Aug 2009 22:02:46 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Doug Barton References: <4A89CB20.3000408@quip.cz> <4A8E2121.6040507@FreeBSD.org> <4A8E8ACA.3060705@quip.cz> <4A8EF583.8090806@FreeBSD.org> <4A9966FE.7060509@quip.cz> <4A998242.80005@FreeBSD.org> <4A999B4A.3000603@quip.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: portmaster is not always recursive X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 20:02:51 -0000 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) 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? The dependency tree is: security/amavisd-new mail/p5-Mail-SpamAssassin archivers/p5-Archive-Tar archivers/p5-IO-Compress-Bzip2 archivers/p5-Compress-Raw-Bzip2 > What I'm seeing in security/php5-mcrypt is that the union of > {build|run}-depends-list is different if I run it in the slave port than > if I run it in lang/php5 (after enabling the OPTION for apache): > > In the slave port: > /usr/ports/devel/autoconf262 > /usr/ports/devel/libltdl22 > /usr/ports/lang/php5 > /usr/ports/security/libmcrypt > > In lang/php5: > /usr/ports/devel/autoconf262 > /usr/ports/devel/pkg-config > /usr/ports/textproc/libxml2 > /usr/ports/www/apache22 > > That's why portmaster is not picking up the dependency on apache when > updating php5-mcrypt. 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? > 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. 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 can imagine some cases with long chain of dependencies (A - B - C - D - E) where user wants to update A, then B, C and D has no updates, but E has update. So if portmaster updates A and E, but not B, C, D it can cause some incompatibilities. Am I right? So in this view, updating only first level dependencies seems better. (but incompatible changes are usually solved by version bump and thus updates for B, C, D) 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. All above are just my thoughts... Thank you again for you explanation of the problem. It is really educational to me. Miroslav Lachman