Opinion on cross-port OPTIONS CONFLICTS
danny at ricin.com
Fri Dec 21 17:40:45 PST 2007
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
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
More information about the freebsd-ports