Port configuracion and compilation

[Matthew Seaman]

On 30/03/2011 20:02, egoitz at 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)...
> 
> 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 and
> 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 course.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20110330/a2f35057/signature.pgp