Date: Wed, 30 Mar 2011 21:15:09 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-ports@freebsd.org Subject: Re: Port configuracion and compilation Message-ID: <4D938F4D.5010401@infracaninophile.co.uk> In-Reply-To: <f0276779b03fb067c34b45a4cceba103@ramattack.net> References: <f0276779b03fb067c34b45a4cceba103@ramattack.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD9575EAFA3761C31AC6B2FFE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 30/03/2011 20:02, egoitz@ramattack.net wrote:
> One little question. I have package collections of packages made
> (packages created by compiling ports and later pkg_create -Rb) for my
> freebsd provisioned releases with the servers I need to provision (mail=
,
> web, etc)...
>=20
> now imagine, someone in some of those provisioned servers (with
> provisioned packages, installed with a pkg_add * from the directory
> where are packages provisioned downloaded from one of my servers) one
> sysadmin goes to compile another port (I install in provisioned servers=
> the ports that come with the installed release which are the same ports=
> as which with I make the provisioned packages) which has as dependency
> an installed package... for example don't know... let's imagine Postfix=
> has libiconv or any as dependency... when you do from
> /usr/ports/mail/postfix a make config-recursive... although libiconv is=
> installed it asks you for compilation options... what happens if the
> user is compiling postfix, sets for example libiconv options as default=
> (with default options) and if the package previously compiled by me for=
> libiconv has not the default options? imagine has less options
> (features) for example... could this break something??. I mean when
> Postfix (or whatever package with installed dependencies) is compiled,
> the freebsd ports system looks for something at /var/db/ports/*/OPTIONS=
> or similar?? or ports are just compiled as the given options to them an=
d
> although you specify anything for installed dependencies in the ncurses=
> menu for configuring the dependency port (launched by config-recursive)=
> it just compiles the port you are compiling (so basically what you want=
> to install, the software is not at the moment on the machine) and with
> the options specified for the compiling port ignoring how dependecies
> are in /var/db/ports/*/OPTIONS?
There isn't a hard and fast rule. Sometimes changing OPTIONS in a
dependency has a trivial effect on anything else in the dependency
chain; other times it can have a very profound effect.
Probably the biggest gotcha is where toggling an option adds a
dependency on some new shlibs. Normally this results in extra packages
being installed as the usual mechanisms for satisfying the dependencies
of whatever ports/packages kick in, and everything is happy. However,
it can result in parts of the dependency chain causing an application to
try and dynamically link against conflicting libraries -- two different
versions of the same library is a typical problem.
In your example of iconv packages compiled with different options,
supposing this led one of those packages to have an additional library
dependency? Well, the LIB_DEPENDS are recorded in the package when it
is created, so the modified pkg would complain if it couldn't find the
extra library or it would cause that package to be installed.
Not all the changes controlled by OPTIONS settings result in changes to
the dependency tree. In these cases it's hard to manage a requirement
for "port foo but with option X enabled" -- generally you would have to
arrange for a slave port with the required settings.
There isn't any record in a compiled pkg of the OPTIONS settings used to
compile it. I've occasionally thought that including that data might be
a good idea -- even to the extent of adding
/var/db/ports/${LATESTLINK}/options to the pkg plist as a matter of cours=
e.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enigD9575EAFA3761C31AC6B2FFE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2Tj1YACgkQ8Mjk52CukIypCACghDhWZ2Gs8HsXiif1gIM8waI2
o/sAnjpYwDGACAKP4wvqhT9t61jgyQmA
=Rcui
-----END PGP SIGNATURE-----
--------------enigD9575EAFA3761C31AC6B2FFE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D938F4D.5010401>