Opinion on cross-port OPTIONS CONFLICTS

[Paul Schmehl]

--On December 22, 2007 12:07:45 AM +0100 Danny Pansters <danny at ricin.com> 
wrote:
>
> I like the idea to do something with options. Optionifying ports is all
> nice  and well, but to make it meaningful, ports should be able to know
> about each  other's options. I actually have been working a bit on a
> proposal that was  similar (it remained in brainstorm phase though ;-).
>
> How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/arts at WITHOUT_NAS to
> squash two  flies at once.
>

Another way to address this would be to create a fourth "tuple".  Right 
now the convention is file:portdir:target.  Why not have 
file:portdir:target:option.

The problem with this whole subject is, what do you do if a port depends 
on another port *and* requires that _more_than_one_option be true?  My 
idea doesn't solve that *unless* you allow a comma separated list or 
something similar.

I think, if you're going to make ports OPTIONS aware, you *must* be able 
to both determine if a port is already installed with or without the 
option *and* install it with the necessary options if it's not already 
installed.

> The idea being that if the port is not installed it yet, it could be
> built  with make WITHOUT_NAS=1 automagically. Something like this is
> more pressing  when you need to have a non-default option set in a port
> you depend on.  However, you should be very careful to not decide things
> on the users behalf  in a port. Consistancy, pola, all that...
>
OTOH, if you can't build your port without a dependency including an 
option, why not mark the port as BROKEN unless the correct file is in 
place?  The first tuple already checks for that, right?  So, instead of 
checking for the default file, check for something the OPTION would 
install.

So:
LIB_DEPENDS=    ldap.so:net/openldap for without the OPTION
or
LIB_DEPENDS=    ldapfoo.so:net/openldap for with the OPTION

That doesn't solve *installing* the dependency correctly without some 
other construct such as the fourth tuple though.

Paul Schmehl (pauls at utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/