Date: Fri, 11 May 2007 01:18:52 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> Cc: freebsd-hackers@freebsd.org, Ivan Voras <ivoras@fer.hr>, Kris Kennaway <kris@obsecurity.org> Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) Message-ID: <20070511051852.GA89359@xor.obsecurity.org> In-Reply-To: <17987.57305.7130.873114@bhuda.mired.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 10, 2007 at 11:15:37PM -0400, Mike Meyer wrote: > In <20070511021249.GA78729@xor.obsecurity.org>, Kris Kennaway <kris@obsec= urity.org> typed: > > On Thu, May 10, 2007 at 10:03:22PM -0400, Mike Meyer wrote: > > > In <20070511015156.GA77895@xor.obsecurity.org>, Kris Kennaway <kris@o= bsecurity.org> typed: > > > > On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: > > > > > In <f20c8u$htp$1@sea.gmane.org>, Ivan Voras <ivoras@fer.hr> typed: > > > > > > I cannot currently actively participate in implementing propose= d things, > > > > > > but I can give advice on sqlite, database and xml schemas if an= yone > > > > > > wants to... > > > > > One of the things that would be nice for a replacement to do woul= d be > > > > > to correctly install i386 packages on amd64 platforms (and similar > > > > > things).=20 > > > > This has nothing to do with a new packaging system and can be done > > > > today if someone cares enough to work on it. > > >=20 > > > Well, yeah - *anything* can be done if someone cares enough to work on > > > it - it's all just SMOP. You could definitely put enough smarts into > > > the package installer do this without actually changing the packaging > > > system. But if we're gonna change the packaging system anyway, why not > > > consider adding information that the package building software already > > > has so that the package installer software doesn't have to try and > > > figure it out? > >=20 > > Sure, we could pile on some more features onto a 6 year old design > > document that never got out of the design phase, or someone could just > > go and make the relatively minor changes to support i386 packages on > > amd64 now. I guess it's always more fun to build dream castles though > > :) >=20 > Last time I looked into this, it didn't look relatively minor to > me. But hey, if there's a document listing what needs to be done > somewhere and it's really relatively minor, I need this bad enough to > deal with that. 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. 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. 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. > 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. > > > > Not gonna happen as a default, but you can change it on your systems > > > > if you like. > > > Not very reliably. > > Best I can offer ;) >=20 > 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. Kris --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGQ/y8Wry0BWjoQKURAjjVAKDBKgwGZme0Qnl96dvBsB8Q3obR1wCdGNYR 8h35fdUFr6E8wShQq4STalE= =m/Cd -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511051852.GA89359>