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

[Kris Kennaway]

On Fri, May 11, 2007 at 10:35:41AM -0400, Mike Meyer wrote:
> In <20070511051852.GA89359 at xor.obsecurity.org>, Kris Kennaway <kris at 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 have to be more careful than this, because a lot of ports have
architecture-dependent on-disk formats for their data files (obviously
not the jpeg example, but there are lots of other cases that use a
non-portable storage format).  In practise avoiding all these
conflicts will be very restrictive: as soon as you have installed a
moderate number of amd64 packages, you lose the ability to install
most i386 packages because of these header/library/data file conflicts
(e.g. you can't install an i386 gtk app if you are running a gnome
desktop).  Which means you're back to installing the i386 packages in
a separate prefix, i.e. option 1.

> > 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.

The point is that the real problem is: "how do you arrange the bits on
disk", not "how do you wrap that in a package system".  Until you
figure out a workable on-disk arrangement for the files, questions
about packaging are not relevant.  And it seems that option 1 is the
only workable one in practise (unless you have some other idea), which
can easily be achieved today with a couple of hours of kernel hacking.

Kris