From owner-freebsd-ports@FreeBSD.ORG Wed Dec 3 22:45:56 2008 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 52BC6106564A for ; Wed, 3 Dec 2008 22:45:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 08D828FC16 for ; Wed, 3 Dec 2008 22:45:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 28536 invoked by uid 399); 3 Dec 2008 22:19:16 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Dec 2008 22:19:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <493705E2.907@FreeBSD.org> Date: Wed, 03 Dec 2008 14:19:14 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Peter Schuller References: <20081203210233.GA55633@hyperion.scode.org> In-Reply-To: <20081203210233.GA55633@hyperion.scode.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: Deterministic package building with 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: Wed, 03 Dec 2008 22:45:56 -0000 Peter Schuller wrote: > Hello, > > I have been in a perpetual multi-year struggle to sort out package > building in a way which is practical for me. One thing I'm confused about here, what are your goals? You don't mention why you need to build the packages. The answer to this might inform the rest of the conversation. > For the past half year or > so I have ended up using a hacked together shell script which does > approximately what I need, which is: > > To build deterministically as a function of > (a) base system > (b) /etc/make.conf > (c) /usr/local/etc/ports.conf (sysutils/portconf) These are givens, but it never hurts to mention requirements explicitly. > (d) a list of specifically desired origins/packages which is manually > mainteined (NOT a complete list of dependencies, this is critical) Why is not maintaining the list of dependencies critical? I'm guessing the answer is related to the dependencies being fluid over time. > (e) the ports tree > a set of packages for later installation on another system > (typically the host system or other jails). I'm assuming this last bit is the answer to my question above, which makes me even more curious as to your comment about the dependencies. > This has *sort* of worked, but not quite. I am fairly close now to > have something that works, but am running into determinism issues. For > example, the dependencies of audio/aumix is a function of what happens > to already be built on the system. So initially when my script wants > to build audio/aumix, it happens to be the case that no X stuff has > been brought in yet, so 'make package-name' returns aumix-x.y.z. Later > on when aumix is picked up as a dependency as part of building > something else, 'make package-name' returns aumix-gtk-x.y.z. This > causes confusion because the tool thinks the "origin"[1] audio/aumix > has not been installed on the system. > > Is it the intent of the design of ports that the behavior of packages > be implicitly dependent on the state of installed packages? > > If the answer is yes, can someone suggest a practically viable that > consistently works, method of building binary packages under the above > conditions? Yes, this is a feature. You could solve the problem you describe above by building the X stuff first. > (I know of portupgrade/portmaster of course. I have never found a tool > that both (1) does what I want What you want is beyond the scope of current tools. I have a proposal for adding this functionality to portmaster but it is a considerable amount of work and therefore I was hoping to get some funding to support it. > and (2) actually works consistently. If you wanted to list the ways that portmaster does not work consistently in a different thread I'd be interested. hth, Doug -- This .signature sanitized for your protection