From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 04:56:18 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B4916A403 for ; Sat, 12 May 2007 04:56:18 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id DEC7913C448 for ; Sat, 12 May 2007 04:56:17 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 72632 invoked by uid 1001); 12 May 2007 04:55:46 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Sat, 12 May 2007 00:55:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17989.18640.420958.755412@bhuda.mired.org> Date: Sat, 12 May 2007 00:55:44 -0400 To: Kris Kennaway In-Reply-To: <20070511191057.GA25833@xor.obsecurity.org> References: <17987.52037.112351.872442@bhuda.mired.org> <20070511015156.GA77895@xor.obsecurity.org> <17987.52970.398402.580727@bhuda.mired.org> <20070511021249.GA78729@xor.obsecurity.org> <17987.57305.7130.873114@bhuda.mired.org> <20070511051852.GA89359@xor.obsecurity.org> <17988.32573.910854.388638@bhuda.mired.org> <20070511184259.GA23483@xor.obsecurity.org> <17988.48879.828384.170557@bhuda.mired.org> <20070511191057.GA25833@xor.obsecurity.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 04:56:18 -0000 In <20070511191057.GA25833@xor.obsecurity.org>, Kris Kennaway typed: > > There are clearly other workable ideas - as I said, the linux folks > > managed to make it work. But it's not an easy problem. I certainly > > wouldn't suggest rebuilding the packaging system to deal with this, > > except as part of a larger effort. On the other hand, since people are > > working on the ports/package system (I see port/pkg database and some > > ports infrastructure work in the current SoC projects list), not > > keeping this goal in mind would seem to be a bit short-sighted. I > > wouldn't be surprised if your option #1 could benefit from this as > > well. > But you said you were interested in working on it...so what is your > idea? Actually, I said it's on my list of things to do. That's a rather long list. I'm more interested in port building, but the dependencies to that one look like: 1) Get a gcc build whose driver correctly handles "-m32" for cross-compiling. The system gcc can do cross-compilation, but the driver doesn't know where the various bits it needs to link the generated objects with live, so you have to tell it about those things by hand. Possibly one of the versions in ports does this, but it would be nice if the one in the base system did this. I believe it's mostly a matter of properly configuring the gcc build. 2) Rework the ports dependency/conflict detection facilities. Mostly, figuring out the architecture of the current build vs. any previously installed packages or ports it depends on or conflicts with. There are also some things that could be done to make the dependencies more reliable, like auto-detecting shared library dependencies and adding those. Having the target platform for an installed package in the package database would be a nice jump on this. 3) Now we get to the interesting part: figuring out where the bits for the cross-installation are going to land. A lot depends on how far apart we want to keep the two worlds. I'd like them to be integrated, as the point of being able to install 32-bit binaries on a 64-bit system is to run applications that aren't yet 32-bit clean, so the only collisions should be shared libraries common to applications from both sets. A lot will depend on how badly things collide. The other factor is that I'd like the build platform to be tranparent to the end user: you should be able to build 32-bit packages on either 32 or 64 bit platforms, and use them on either. This ties back to the "How do we figure out where our libraries are" issue. I don't know if all these goals can be met. 4) Once that's done, start working on getting cross-building and installing ports working. This is a long way from any work being done on it, so I don't have any details. Doing step #2 would help with fleshing out these step. 5) Now make make building packages from those ports and installing from those packages work. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.