New FreeBSD package system (a.k.a. Daemon Package System (dps))
mwm-keyword-freebsdhackers2.e313df at mired.org
Sat May 12 05:55:15 UTC 2007
In <20070512052038.GA57479 at xor.obsecurity.org>, Kris Kennaway <kris at obsecurity.org> typed:
> > > 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.
Ah, sorry - I thought you were referring to my comment when I first
brought this up. Yeah, if there were a minor fix that gave me the
integrated environment I want, that I'd do.
> 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
There are already solutions using an emulated environment that don't
require any work on my part.
> > 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).
Actually, I need this more than I need 32 bit packages to install.
> 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".
You may well be right. On the other hand, the linux folks seem to have
come up with something they thought was worthwhile, which to me
> 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 :)
Not interested in doing option 1. There are easier ways to get a
segregated 32-bit environment. Yeah, it'd be a little bit better
coupled, and some people might think that's worth spending a day or
two on, but I'm not one of them.
Personally, I think a year or two might be a bit optimistic.
Mike Meyer <mwm at mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
More information about the freebsd-hackers