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

On Thu, May 10, 2007 at 11:15:37PM -0400, Mike Meyer wrote:
In <20070511021249.GA78729@xxxxxxxxxxxxxxxxxx>, Kris Kennaway <kris@xxxxxxxxxxxxxx> typed:
On Thu, May 10, 2007 at 10:03:22PM -0400, Mike Meyer wrote:
In <20070511015156.GA77895@xxxxxxxxxxxxxxxxxx>, Kris Kennaway <kris@xxxxxxxxxxxxxx> typed:
On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote:
In <f20c8u$htp$1@xxxxxxxxxxxxx>, Ivan Voras <ivoras@xxxxxx> typed:
I cannot currently actively participate in implementing proposed things,
but I can give advice on sqlite, database and xml schemas if anyone
wants to...
One of the things that would be nice for a replacement to do would be
to correctly install i386 packages on amd64 platforms (and similar
things).
This has nothing to do with a new packaging system and can be done
today if someone cares enough to work on it.

Well, yeah - *anything* can be done if someone cares enough to work on
it - it's all just SMOP. You could definitely put enough smarts into
the package installer do this without actually changing the packaging
system. But if we're gonna change the packaging system anyway, why not
consider adding information that the package building software already
has so that the package installer software doesn't have to try and
figure it out?

Sure, we could pile on some more features onto a 6 year old design
document that never got out of the design phase, or someone could just
go and make the relatively minor changes to support i386 packages on
amd64 now. I guess it's always more fun to build dream castles though
:)

Last time I looked into this, it didn't look relatively minor to
me. 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.

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.

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.

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.

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

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.

Kris

Attachment: pgpu0OL2gIdRF.pgp
Description: PGP signature

Relevant Pages

  • Errors applying kernel patch 118833-36
    ... install of Solaris 10 11/06. ... However, once the package list is done, I see a worrisome message: ... Below is the complete console output of the patch run. ... Changes for package SUNWnfsskr will not be applied to the system. ...
    (SunManagers)
  • Re: media player 10 setup issues
    ... Finished building install list. ... Package 'MPPRE' is version '10.0.0.3802'. ... Install for Exception pack ...
    (microsoft.public.windowsmedia)
  • Re: A little help please!
    ... This so far was the best map to getting DVD media working I am going to ... Also I have the latest libdvdcss2 and libdvdcss2-dev installed. ... sudo aptitude install totem-xine ... Click either free or non-free depending on where the package you ...
    (Ubuntu)
  • Re: Code correctness, and testing strategies
    ... automate the testing a bit more. ... the shell scripts & control files work correctly, that the debian ... package had all the files in the correct places etc). ... Install the package under a chroot ...
    (comp.lang.python)
  • Re: from x86_64 only back to i386 support
    ... Finished Transaction Test ... of glib2-2.14.4-1.fc8.i386 conflicts with file from package ... install of glib2-2.14.4-1.fc8.i386 conflicts with file from package ...
    (Fedora)