Subject: Re: Optional Dependancies
To: Chris Gilbert <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 04/21/2001 08:02:09
On Sat, 21 Apr 2001, Chris Gilbert wrote:

> Optional dependancies will allow the ability to have extra features turned on
> if you have that package installed.  Eg kdepim2 would enable kpilot if you've
> got misc/pilot-link installed, something that not everyone would want but
> some might.  It might also assist in cases of circular dependancies.

How? Please explain.

> How do we handle binary packages?
> My suggestion would be that if an optional package was found on the build
> system then it becomes a dependancy for that binary package.  This will
> complicate doing bulk builds, but it depends on how many optional
> dependancies there are.  However to handle this it would perhaps be worth
> having a global flag saying ignore optional dependancies.

Having "indeterminate" binary packages would really suck. New users
would ask, "How come package foo gets installed on i386, but not on
{sparc,m68k,alpha}.  Aren't {sparc,m68k,alpha} fully supported?"

As it is, it's possible to install "kde" and "gnome" from binary
packages only about half the time -- it depends on how conscientiously
the builder updated all the dependencies. This looks to me like one
more thing to go wrong.

> OPTIONAL_DEPENDS +=	pilot-link>=0.9.3:../../misc/pilot-link:message about
> what this extra package will add.
> If it finds something in the OPTIONAL_DEPENDS section installed it adds it to
> DEPENDS.  If it doesn't find the package it can optionally display the
> message as to what functionality would be added.
> If an optional package needs to set options to enable the functionality some
> way of detecting this might be needed eg:
> .if ${OPT_pilot-link}
> 	CONFIGURE_ENV+=  -enable-palm-link
> .endif

This could all be accomplished within the existing framework...

.include ../../mk/

DEPENDS+=		pilot-link>=0.9.3:../../misc/pilot-link
CONFIGURE_ENV+=		--enable-palm-link

.include ../../mk/

with an appropriate entry in mk.conf.example.

The above would turn it on by default. The rule is to build the
packages as full-featured as possible, unless there's a good reason
not to, like if the dependency introduces a more restrictive license.