Subject: Re: USE_SASL is too general?
To: Adam C. Migus <adam@migus.org>
From: Daniel Eggert <eggert@macvaerk.dtu.dk>
List: tech-pkg
Date: 12/30/2003 22:57:59
On Tuesday, December 30, 2003 9:30 PM, Adam C. Migus wrote:
> On Tuesday 30 December 2003 02:50 pm, Daniel Eggert wrote:
> > On Tuesday, December 30, 2003 8:06 PM, Adam C. Migus typed:
> > > On Tuesday 30 December 2003 01:12 pm, Daniel Eggert wrote:
> > > > > On Monday 29 December 2003 06:10 pm, grant beattie wrote:
> > > > > > On Mon, Dec 29, 2003 at 06:08:21PM -0500, Adam C. Migus
> > > > > > wrote:
> > > >
> > > > <snip>
> > > >
> > > > > So then why do the variables _need_ to be per-package?  I
> > > > > actually like being able to say USE_{SOMETHING} and know it
> > > > > means "if a package has support for {SOMETHING} I want to
> > > > > compile it in..."
> > > >
> > > > One good example: I have mail/postfix, security/sasl and
> > > > databases/openldap. I need to compile postfix with sasl and
> > > > openldap support and I need sasl with openldap support. This
> > > > doesn't work if openldap is compiled with sasl support as it will
> > > > create a circular dependency and everything wil break once I try
> > > > to 'make update'.
> > >
> > > The fact that using USE_SASL creates a circular dependency when
> > > doing make update in this situation is a problem with the logic in
> > > update. Solving it by not defining USE_SASL is like trying to avoid
> > > breaking your leg by not walking.
> >
> > Well, both yes and no: Circular dependencies break "make update"
> > because they "have to". Circular dependencies are bad per-se -- with
> > and without "make update".
> >
>
> All I'm saying is the circular dependency should be fixed in make and
> pkg_ utilities not by trying to avoid it with feature restriction.
>

Maybe I'm mistaken, but here's my arguing:

If you build package a that has feature A and package b that has feature B
and then package a can facilitate feature B and package b can facilitate
feature A there will be a circular dependency and you will need to define
either package a not to use feature B or package b not to use feature A.

Else, if you install a 1st and then b and then reinstall (update) a, a will
use feature B and b will use feature A. In this situation you're stuck. You
cannot uninstall a as it is needed by b and you cannot uninstall b as it is
needed by a.

/Daniel