From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 14:36:14 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 7E6BD16A400 for ; Fri, 11 May 2007 14:36:14 +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 2F6CB13C45A for ; Fri, 11 May 2007 14:36:14 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 39024 invoked by uid 1001); 11 May 2007 14:35:42 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Fri, 11 May 2007 10:35:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17988.32573.910854.388638@bhuda.mired.org> Date: Fri, 11 May 2007 10:35:41 -0400 To: Kris Kennaway In-Reply-To: <20070511051852.GA89359@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> 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: Fri, 11 May 2007 14:36:14 -0000 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'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. > > On the other hand, if no one has actually done the > > work to figure out what this would really take, is wishful thinking > > really enough to keep a very desirable feature (well, it's desirable > > enough that most Linux platforms seem to offer it) from even being > > considered? > You misunderstand me: by all means people should work on improving our > package infrastructure -- but it's wrong to pin your hopes on a > possibly mythical future event when you can easily solve a problem > today. Oh, I've been dealing with BSD long enough to know better than to pin my hopes on such things. Even doing it may not be enough - you still have to get someone to *commit* it. On the other hand, someone stepped up and said "We're going to rework the package system." I don't think it's to much to ask that they keep this requirement in mind. > > > > > Not gonna happen as a default, but you can change it on your systems > > > > > if you like. > > > > Not very reliably. > > > Best I can offer ;) > > > > Is this the new motto for FreeBSD? Good QA practices would have the > > ports built with that knob set to something something other than the > > default at regular intervals. Lately things have been better, but > > I've found broken things in the last twelve months. > You'll be delighted to know that I have been doing precisely this for > the past few years. If you're interested I'll CC you the errors from > my next build so you can help work on improving compliance. Actually, what i'm delighted about is that I actually noticed things were getting better - the last time I did a near-complete set of upgrades, nothing broke because of LOCALBASE having a non-default setting. I had figured this was just do to people reporting such bugs - I know I always do. It seems that you're responsible. Thank you. I still think we ought to quit pretending that ports/packages aren't part of BSD, and default LOCALBASE to /usr. But if changing it is being tested, that's a big help. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.