New FreeBSD package system (a.k.a. Daemon Package System (dps))

[Mike Meyer]

In <20070511191057.GA25833 at xor.obsecurity.org>, Kris Kennaway <kris at 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. 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.

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.

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.

4) Once that's done, start working on getting cross-building and
   installing ports working. This is a long way from any work being
   done on it, so I don't have any details. Doing step #2 would help
   with fleshing out these step.

5) Now make make building packages from those ports and installing
   from those packages work.

   	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.