Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jun 2014 23:07:09 +0200
From:      Polytropon <freebsd@edvax.de>
To:        Walter Hurry <walterhurry@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: pkg: Can't install pgAdmin3
Message-ID:  <20140625230709.38754fa2.freebsd@edvax.de>
In-Reply-To: <lofcfo$h4l$1@ger.gmane.org>
References:  <lo6roc$nf$1@ger.gmane.org> <F9D47E26F1CB4140BC37ED2EC70D8CC8@gmail.com> <lofcfo$h4l$1@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Jun 2014 20:46:48 +0000 (UTC), Walter Hurry wrote:
> But my question remains: What is lacking in the architecture of 
> pkg that it cannot cope with this?

It's not possible to create and continuously update a
repository for all imaginable combinations of possible
options and required dependencies concluded from those
options.

Just imagine you have a program "foo" with those options:
	"bar": requires "baz" (default: on)
	"qux": requires "moo" (default: off) (dependency: "cluck")
	dependencies: "meow"
So the "foo" binary package will install with the "bar"
functionality and add the "meow" dependency. But if "moo"
set for "foo", will also require the "cluck" dependency.

This would result in the following packages:
	"foo" with "bar", without "moo", dependency "meow"
	"foo" without "bar", without "moo", dependency "meow"
	"foo" without "bar", with "moo", dependencies "meow", "cluck"
	"foo" with "bar", with "moo", dependencies "meow", "cluck"

What kind of naming scheme should be applied to identify the
various available packages? Is maintaining 2^n packages for
n options actually possible? What if side effect to otherwise
unrelated ports occur?

And now imagine a port like mplayer with its dozens of options
for various codecs and the possibility of additional settings
and compile time options. It would be nonsense to provide a
precompiled binary package for each, so the developers chose
to be careful to define the "most common and most usable" set
of default options which is used for building the packages.

If you need anything that's _not_ mapped to the default options,
you still need to compile your stuff - either with "poudriere"
or using the classic "make config && make install" approach
(while you can partially combine them with pkg, for example
by first running "make missing" and have pkg install binary
packages for most dependencies, then running the actual
compiling for the port in question).

Binary packages can do a lot, but they can't do magic. :-)

In combination with such "customized" ports, pkg will still
correctly update the system database in regards of used options
and caused dependencies so updates are possible. A "poudriere"
installation can be very helpful in the updating process if you
have a lot of ports where you cannot use the default options.
A problem as described above does not exist when using "bare"
ports.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140625230709.38754fa2.freebsd>