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/[EMAIL PROTECTED] 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 _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"