From owner-freebsd-ports@FreeBSD.ORG Tue Feb 7 07:19:49 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3B6A16A420 for ; Tue, 7 Feb 2006 07:19:48 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 687AC43D4C for ; Tue, 7 Feb 2006 07:19:47 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 8563 invoked by uid 399); 7 Feb 2006 07:19:46 -0000 Received: from localhost (HELO ?192.168.1.102?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Feb 2006 07:19:46 -0000 Message-ID: <43E84A10.2050201@FreeBSD.org> Date: Mon, 06 Feb 2006 23:19:44 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Panagiotis.Astithas@ebs.gr References: <43D610B6.5080008@FreeBSD.org> <43DE40FE.6000507@ebs.gr> <43DE6C65.9040306@FreeBSD.org> <43DE7652.9050807@ebs.gr> <43DF346B.407@FreeBSD.org> <43DF40BC.4060600@ebs.gr> <43E2B3A6.9060508@FreeBSD.org> <43E2B530.4050500@FreeBSD.org> <20060203065504.GA3857@weller-fahy.com> <43E31808.6070205@FreeBSD.org> <20060203111911.GA22446@hal.ebs.gr> In-Reply-To: <20060203111911.GA22446@hal.ebs.gr> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: New /bin/sh based script to manage ports 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: Tue, 07 Feb 2006 07:19:49 -0000 Panagiotis Astithas wrote: > On Fri, Feb 03, 2006 at 12:44:56AM -0800, Doug Barton wrote: >> This depends on which direction you're approaching the problem from. When >> building a port, the check for whether the dependencies of the port are up >> to date uses the list from 'make all-depends-list', which will include build >> dependencies. However, once a port has been built and installed >> successfully, the list of ports which have a dependency on the updated port >> is cross checked between the +REQUIRED_BY in the package directory and the >> +CONTENTS files of the other installed ports. In this way we can be sure >> that all appropriate dependencies are recorded, and updated. Since >> BUILD_DEPENDS are not registered in the +CONTENTS or +REQUIRED_BY files, >> they don't show up at that stage, and portmaster doesn't update information >> about them (because that information doesn't exist). > > And I've noticed that portmaster warns when there is a mismatch between > the dependencies in +CONTENTS and +REQUIRED_BY, where the latter are usually > more than the former. However the default suggestion from portmaster is > to use the +CONTENTS dependencies. Why is there a difference in the first > place (port bugs I presume) and would the other approach be more correct > (in that it would fix the unrecorded dependencies)? Well, not having dependencies recorded in the +CONTENTS files, but having them in +REQUIRED_BY would be fairly pathological. When the port or package is built, it records its own dependencies in +CONTENTS, so that should always be accurate, for sufficiently careful definitions of "always" and "accurate." I'm not sure how you'd get a line for a port in +REQUIRED_BY in a way that didn't let you get it back out again. That's why the default when there is a mismatch is actually to use the +REQUIRED_BY set. One common case where there will be a mismatch is a case like gtk-1 and gtk-2. grep'ing for "gtk-" pkgdeps will get you both, so there is a mismatch. However in a case like that the differences should be obvious. > On another note, I tried yesterday a 'portmaster -rdf expat', which is a > mega task on my system, so I would expect to get preferably zero questions > asked (since we are talking about 200 ports here). This is what the relevant > portupgrade invocation did (modulo the various OPTIONS screens), although > 20 hours later it is still not finished. Could portmaster be persuaded to > 'do whatever needs to be done, but you are on your own until you do it'? Boy, you're just full of fun. :) First a meta-comment, I didn't rush to add the -r option because in my experience, it's hardly ever necessary to rebuild ports that depend on a port that you're going to be updating. One of the few where I've found this necessary is gnutls, and then only for some of the ports that depend on it. At least 95% of the time, I just update a port, and the ports that depend on it still work. This is one of the joys of shared libraries. :) If you need to use the -r option, I would not recommend adding the -f flag, as that would rebuild all of the dependencies of the ports that depend on the -r port, which probably isn't necessary at all. I wrote the -r option code to always rebuild the ports that depend on the port you specify with -r, so the -f flag isn't needed to accomplish that. Now to the substance of your question. I added the -[dD] options to help with exactly the problem you describe. BTW, another way to speed the build in this type of situation is to add the -C option. All that said, I'm not exactly sure what you're asking for. If you're saying that you want an option to suppress questions about updating dependency listings, I suppose that could be added easily enough, but I would be very hesitant about that. OTOH, I suppose we've not hesitated to put bullets in the foot-shooting gun before, why stop now. :) If you can clarify what you're looking for here, I'll look at adding it. Doug -- This .signature sanitized for your protection