On Tuesday 30 December 2003 04:57 pm, Daniel Eggert wrote:
> 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

This is a problem with dependencies and `make update' especially since 
in this context all of this assumes that USE_ implies dependency on a 
package which is not always true as USE_ can tweak ./configure 
arguments, etc.

My bottom line:

1) Cyclic dependencies should be fixed not avoided.

2) The issue of cyclic dependencies is different from the issue of USE_ 
variables (see previous paragraph).

3) You agree with the proposed solution to the USE_ variable issue.

4) I don't want to argue about fixing cyclic dependencies as I've made I 
feel I've made my point (see #1).

End # reached?

Adam