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

In <20070511051852.GA89359@xxxxxxxxxxxxxxxxxx>, Kris Kennaway <kris@xxxxxxxxxxxxxx> 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
today.

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.

Thanks,
<mike
--
Mike Meyer <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Strange capture of my eth0 interface.
    ... but I doubt if there is any connection. ... so I did a fresh install. ... > then seeing that the package manager does indeed detect the switch - don't ... > Port numbers are like telephones. ...
    (comp.os.linux.security)
  • Re: YAPIB (was: Drawing graphics on terminal)
    ... if I want to install package A which requires B and C, ... This reduces the likelihood that network installs will get ... package sources without having to go bug the "Official FreeBSD FTP Package ... be automatically starting a port compile just because it notices that there's ...
    (freebsd-hackers)
  • Re: amd64 questions
    ... so if you want to install a 64 bit package ... install of a 32-bit pkg with its dependencies. ... them (ie libraries in /usr/lib32). ... have a broken copy of the tarball the port is using. ...
    (freebsd-hackers)
  • Re: Slight problem with make actual-package-depends with ports
    ... After you have made and installed a port, but don't clean it, and then ... then do "make package", then +CONTENTS can be a bit messed up for the ... which is in the middle of the dependency tree with options which change ... "make install" before you install any other ports. ...
    (freebsd-hackers)
  • Re: amd64 questions
    ... amd64 object files. ... so if you want to install a 64 bit package ... My copy of the port sets that for amd64 already. ...
    (freebsd-hackers)