Date: Fri, 21 Dec 2007 18:33:41 -0600 From: Paul Schmehl <pauls@utdallas.edu> To: freebsd-ports@freebsd.org Subject: Re: Opinion on cross-port OPTIONS CONFLICTS Message-ID: <DDD0A7F68046C4F9F3CB3D97@paul-schmehls-powerbook59.local> In-Reply-To: <200712220007.45753.danny@ricin.com> References: <200712211524.25454.josh@tcbug.org> <20071221214319.GI40969@k7.mavetju> <200712220007.45753.danny@ricin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--On December 22, 2007 12:07:45 AM +0100 Danny Pansters <danny@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@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@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DDD0A7F68046C4F9F3CB3D97>