New FreeBSD package system (a.k.a. Daemon Package System (dps))
mwm-keyword-freebsdhackers2.e313df at mired.org
Fri May 11 14:36:14 UTC 2007
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'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.
> > 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
Oh, I've been dealing with BSD long enough to know better than to pin
my hopes on such things. Even doing it may not be enough - you still
have to get someone to *commit* it. On the other hand, someone stepped
up and said "We're going to rework the package system." I don't think
it's to much to ask that they keep this requirement in mind.
> > > > > Not gonna happen as a default, but you can change it on your systems
> > > > > if you like.
> > > > Not very reliably.
> > > Best I can offer ;)
> > 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.
Actually, what i'm delighted about is that I actually noticed things
were getting better - the last time I did a near-complete set of
upgrades, nothing broke because of LOCALBASE having a non-default
setting. I had figured this was just do to people reporting such bugs
- I know I always do. It seems that you're responsible. Thank you.
I still think we ought to quit pretending that ports/packages aren't
part of BSD, and default LOCALBASE to /usr. But if changing it is
being tested, that's a big help.
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