Date: Sat, 22 Dec 2007 01:55:47 +0100 From: "Danny Pansters" <danny@ricin.com> To: pav@freebsd.org Cc: freebsd-ports@freebsd.org Subject: Re: Opinion on cross-port OPTIONS CONFLICTS Message-ID: <200712220155.48097.danny@ricin.com> In-Reply-To: <1198283363.95955.11.camel@ikaros.oook.cz> References: <200712211524.25454.josh@tcbug.org> <200712220007.45753.danny@ricin.com> <1198283363.95955.11.camel@ikaros.oook.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 22 December 2007 01:29:23 Pav Lucistnik wrote: > Danny Pansters p=C3=AD=C5=A1e v so 22. 12. 2007 v 00:07 +0100: > > How about e.g. LIB_DEPENDS=3Dartsdsp:/usr/portss/arts@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=3D1 automagically. Something like this is m= ore > > 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= =20 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=20 slave port. I'm not sure if we'd actually want this now, considering the=20 baggage (esp with pkgs, I barely considered them). You can always do local "discovery" inside a particular port by looking at= =20 installed files, or grepping ldd, or other specific hackery -- including=20 grepping on /var/db/ports/foo/options -- and you will be able to cater to=20 that port's needs that way and guide (not force) the user. Even this is har= d,=20 if not impossible to put into packages/plist. There may come a time when it's decided to either have vanilla plists and=20 seperate one(s) with options or dont track plists for non default options a= t=20 all. I bet most/many non-default ports don't get properly packaged anyway a= s=20 it is. What I mean is, that maybe we shouldn't even try to support packaging=20 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 t= hat=20 is going to be inevitable in the near future. Are you, or any other folks, aware of any projects (not ones that were=20 recently on this ML!! :) that are working on a radical modernization of=20 ports? Not that I feel we necessary need one here and now, but I'm interest= ed=20 in any (serious, as in code) ports-v2 efforts. cmake has many useful=20 ports-like features. Cheers,=20 Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712220155.48097.danny>