From owner-freebsd-ports@FreeBSD.ORG Thu Nov 22 19:13:46 2007 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 9CF4B16A468; Thu, 22 Nov 2007 19:13:46 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-122.sea1.dsl.speakeasy.net [64.81.163.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6922A13C459; Thu, 22 Nov 2007 19:13:46 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from [192.168.1.16] (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id lAMJDiIQ061915; Thu, 22 Nov 2007 11:13:44 -0800 (PST) (envelope-from jcw@highperformance.net) Message-ID: <4745D4E7.6090907@highperformance.net> Date: Thu, 22 Nov 2007 11:13:43 -0800 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Barton References: <474262D5.3010603@highperformance.net> <47459C80.8000206@highperformance.net> <4745C795.5020101@FreeBSD.org> In-Reply-To: <4745C795.5020101@FreeBSD.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Cc: freebsd-ports@FreeBSD.org Subject: Re: Package Building in the Large 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: Thu, 22 Nov 2007 19:13:46 -0000 Most of the message below is just rounding out the discussion. There is one significant question on recursion though. Doug Barton wrote: >> I also ended up with shared a library version problem >> in at least one port (grip) in spite of having started my build with a >> completely vacant /usr/local. > > That sounds like a problem with the ports. I can't think of any way > that portmaster would cause that. It might be due to a non-clean /usr/local on the target install host. It was a foo.so.3 is required but foo.so.2 is installed sort of error. I haven't dealt with the installation step in a meaningful way yet. Don't worry about responding to this bit. >> It looks to have good port upgrading abilities, >> but that is not what I am after. What I am trying to do is operate a >> build host and distribute packages from there. > > That is not its primary purpose, but assuming that your systems are > similarly configured, and running an OS version that's fairly close in > age, there is no reason that portmaster shouldn't be able to at least > create the packages that you can then distribute manually. All my systems run a -release and all ports are tagged with the same -release. (With a few odd cases when security issues demand.) A few years ago I decided to stop tracking -stable and just run pure releases. I now spend less time administering my five or so systems. By what you claim, portmaster should suffice. >> I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run >> where $pmarg was the list of 31 ports. > > That's definitely not going to work, for several reasons. The -G > switch should only be used _after_ you've already run portmaster > without it for a given port build. I had manually run 'make config-recursive' previously. I'll do as advised at any rate. > I'm also unsure > what /usr/ports/ports is supposed to be, unless that's a local path > issue. It's a local hierarchy issue. I pushed the ports tree up one level and therein lie 6.2, -current, and the soon to be 7.0 trees. /usr/ports/ports is a link to the tree I was working on in which is /usr/ports/ports-current. Once the FreeBSD portmanager pulls the trigger I will be dealing with 7.0 exclusively. > Assuming that your list of ports is relative to the /usr/ports > directory (e.g., 'archivers/unzip astro/planets', etc.), what I would > do is: > for dir in $pmarg; do > portmaster -BgD -p /usr/ports/$dir > done Aha! I had an error (don't recall exactly) without using -p where the complaint had something to do with not finding something in /usr/ports. So I fired up the manual and then found the -p switch and assumed that was how I told portmaster where the ports tree was stored. I think this is the ticket. I don't have my manpages handy right now but I'll take a closer look. But what about recursion? I held the notion the portmaster did magically delicious recursion and so I thought that providing the list of ports to a single invocation of portmaster would allow portmaster to sort the build order correctly. The code snippet you show would cause portmaster to _forget_ recursion information during each iteration of the loop. My concern was that some dependencies would be built more than once. That's dog slow. > Replace the literal "/usr/ports/" in that string with the actual > location of your ports tree if its different. You probably also want > to add the -v switch in there for the first few runs to familiarize > yourself with what's going on, and review the man page. > Please note, I am not saying that portmaster will definitely be the > right solution for you. However, I do think it's worth pointing out > that if used properly it should at least be able to do what it says it > can do. I'll give it another go. Later, Jason