Opinion on cross-port OPTIONS CONFLICTS

[Danny Pansters]

On Saturday 22 December 2007 01:29:23 Pav Lucistnik wrote:
> Danny Pansters píše v so 22. 12. 2007 v 00:07 +0100:
> > How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/arts at WITHOUT_NAS to
> > squash two
> > flies at once.
> >
> > 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...
>
> This would not work for the packages. How would you represent such a
> dependency line in a package?

Hmm, yes, I think I know what you mean. OPTION_DEPENDS has similar problem 
unless specifically listed in plist + some magic. Bummer.

> That's why you do slave port with an option toggled, when you need a
> package you can depend on. OPTIONS haven't changed this aspect.

But you can't readily specify option X enabled, option Y disabled on that 
slave port. I'm not sure if we'd actually want this now, considering the 
baggage (esp with pkgs, I barely considered them).

You can always do local "discovery" inside a particular port by looking at 
installed files, or grepping ldd, or other specific hackery -- including 
grepping on /var/db/ports/foo/options -- and you will be able to cater to 
that port's needs that way and guide (not force) the user. Even this is hard, 
if not impossible to put into packages/plist.

There may come a time when it's decided to either have vanilla plists and 
seperate one(s) with options or dont track plists for non default options at 
all. I bet most/many non-default ports don't get properly packaged anyway as 
it is.

What I mean is, that maybe we shouldn't even try to support packaging 
non-default builds, and leave it to the person behind the keyboard instead.
Not because I like this option so much, but because I fear something like that 
is going to be inevitable in the near future.

Are you, or any other folks, aware of any projects (not ones that were 
recently on this ML!! :) that are working on a radical modernization of 
ports? Not that I feel we necessary need one here and now, but I'm interested 
in any (serious, as in code) ports-v2 efforts. cmake has many useful 
ports-like features.

Cheers, 

Dan