From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 18:43:01 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 79C1A16A419 for ; Fri, 11 May 2007 18:43:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5B63513C43E for ; Fri, 11 May 2007 18:43:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id CC7C11A3C19; Fri, 11 May 2007 11:43:46 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D7C7051F44; Fri, 11 May 2007 14:42:59 -0400 (EDT) Date: Fri, 11 May 2007 14:42:59 -0400 From: Kris Kennaway To: Mike Meyer Message-ID: <20070511184259.GA23483@xor.obsecurity.org> References: <200705102105.27271.blackdragon@highveldmail.co.za> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17988.32573.910854.388638@bhuda.mired.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-hackers@freebsd.org, Ivan Voras , Kris Kennaway 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: Fri, 11 May 2007 18:43:01 -0000 On Fri, May 11, 2007 at 10:35:41AM -0400, Mike Meyer wrote: > In <20070511051852.GA89359@xor.obsecurity.org>, Kris Kennaway typed: > > There are a few ways you can go. The simplest is to install a > > complete i386 world in e.g. /compat/ia32 and have i386 packages > > installed there, and change the kernel to do a "magic directory > > lookup" for i386 binaries that does path munging like the linuxulator > > does with /compat/linux. > > Actually, the simplest is to install a virtual machine and just use > that. But none of these is quite ideal. > > > If you want the i386 packages to live in /usr/local alongside the > > amd64 packages, you'll need to do something like adding an @arch > > directive to the +CONTENTS file recorded in /var/db/pkg, and add some > > checking to pkg_add to ensure that when you install a package, > > everything it depends on was built for the same architecture. > > Which is pretty much what I pointed out in my original request. Except > you don't really need everything it depends on to be built for the > same architecture. If your port needs gmake to build, or uses > ghostscript to do ps->jpeg conversion or some such, it won't really > care what architecture the executables were built for - just that they > run. It would help if requirements were flagged with whether or not > they required the same architecture. You have to be more careful than this, because a lot of ports have architecture-dependent on-disk formats for their data files (obviously not the jpeg example, but there are lots of other cases that use a non-portable storage format). In practise avoiding all these conflicts will be very restrictive: as soon as you have installed a moderate number of amd64 packages, you lose the ability to install most i386 packages because of these header/library/data file conflicts (e.g. you can't install an i386 gtk app if you are running a gnome desktop). Which means you're back to installing the i386 packages in a separate prefix, i.e. option 1. > > You'd need to also add these checks to bsd.port.mk so it exits > > gracefully when someone tries to natively compile a port for which > > non-native dependencies are installed (e.g. it's going to be really > > unhappy if it finds i386 headers or libraries). This method might be > > more trouble than it's worth. > > Again, it might or might not be unhappy. But now you're venturing into > ports as opposed to the package system. I have a whole other list of > things to consider there. The point is that the real problem is: "how do you arrange the bits on disk", not "how do you wrap that in a package system". Until you figure out a workable on-disk arrangement for the files, questions about packaging are not relevant. And it seems that option 1 is the only workable one in practise (unless you have some other idea), which can easily be achieved today with a couple of hours of kernel hacking. Kris