Date: Fri, 11 May 2007 10:35:41 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-hackers@freebsd.org, Ivan Voras <ivoras@fer.hr> Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) Message-ID: <17988.32573.910854.388638@bhuda.mired.org> In-Reply-To: <20070511051852.GA89359@xor.obsecurity.org> References: <200705102105.27271.blackdragon@highveldmail.co.za> <f20c8u$htp$1@sea.gmane.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
In <20070511051852.GA89359@xor.obsecurity.org>, Kris Kennaway <kris@obsecurity.org> 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, <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17988.32573.910854.388638>