From owner-freebsd-ports@FreeBSD.ORG Tue Feb 7 09:32:50 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 9F26916A420; Tue, 7 Feb 2006 09:32:50 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (dslcustomer-239-113.vivodi.gr [83.171.239.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C7E43D45; Tue, 7 Feb 2006 09:32:49 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id k179WmSg045087; Tue, 7 Feb 2006 11:32:48 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (ajax.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id k179Wlcw093003; Tue, 7 Feb 2006 11:32:48 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43E86940.7070302@ebs.gr> Date: Tue, 07 Feb 2006 11:32:48 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Thunderbird 1.5 (X11/20060203) MIME-Version: 1.0 To: Doug Barton 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> <43E84A10.2050201@FreeBSD.org> In-Reply-To: <43E84A10.2050201@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 09:32:50 -0000 Doug Barton wrote: > 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. Mmm, I see. The last time I saw this it could have been gtk. >> 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 This makes sense. So I guess the instructions in UPDATING are mainly for curing ports that use static linking. > 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. Thanks for the tip. > 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. I was referring to questions like, 'update port X? [n]' and 'delete foo.tgz? [n]'. I figured, since I asked for a '-rd' update, this was redundant. It is not very annoying, unless you have a few hundred ports to update. Although, given your advice above, I will be doing it less often. I should also confess that I'm contemplating a completely non-interactive invocation of portmaster from sysutils/bpm or similar, where such prompts would be prohibitive. Thanks, Panagiotis