Date: Sat, 12 May 2007 01:20:38 -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: <20070512052038.GA57479@xor.obsecurity.org> In-Reply-To: <17989.18640.420958.755412@bhuda.mired.org> References: <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> <17989.18640.420958.755412@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 12, 2007 at 12:55:44AM -0400, Mike Meyer wrote: > In <20070511191057.GA25833@xor.obsecurity.org>, Kris Kennaway <kris@obsecurity.org> 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. You might have meant this, but to quote what you actually said: -- 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. -- I replied with an extremely minor way to solve the problem (adjust freebsd32 file lookups to check /compat/ia32 first), but apparently you don't really need it bad enough to actually go and solve the problem in a day when you could not-really-solve it in a year instead :) > 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. Yes, this would be nice. To a first approximation it's not needed though: you can either use the precompiled i386 packages, or build in your /compat/ia32 chroot (cf Gabor's work to automatically install ports inside a chroot, which would extend trivially to this case to work automatically). > 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. This was part of my "option 2" > 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. So was this. As I discussed, my experience suggests that it is unlikely this can be solved without imposing severe limitations on the packages that may be concurrently installed, so in practise I expect it to be an insufficiently general solution and not worth pursuing, as opposed to the trivially implemented, completely general "Option 1". Anyway, either you're interested in doing option 1 or you're not...if you are, I'll be happy to support your work and shepherd it into the tree. Otherwise, best of luck with that to-do list and we'll chat some more in a year or two :) Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070512052038.GA57479>