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>