On Mon, 28 Dec 2009 23:31:44 +0100 Rémi Cardona <[email protected]> wrote:
> Le 28/12/2009 22:04, Fabio Erculiani a écrit : > > On Mon, Dec 28, 2009 at 9:51 PM, David Leverton > > <[email protected]> wrote: > >> On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: > >>> What all this has to do with the fact that they are just > >>> build dependencies? Just wondering. > >> > >> They're not just build dependencies. They're required to > >> use the library in a certain way, namely to compile other > >> programs against it. As long as we don't have > >> compile-against dependencies, the only correct way to > >> express that is RDEPEND (and also DEPEND because > >> they're /also/ needed to build the library itself). > > > > To me you are saying that DEPEND would work just fine. No? > > No, but I understand why you're insisting. It took us a few > weeks to wrap our heads around this to understand it. > > Let's take an example (bug #228211 but there are dozens more). > > In this example, libfakekey does : #include <XTest.h> > > and its configure.ac checks for "xtst.pc". Both files are > provided by x11-libs/libXtst so this dep is added to DEPEND and > RDEPEND. > > The problem comes from libXtst's XTest.h which #includes > <XInput.h> which was provided by x11-proto/inputproto [1]. > > inputproto is/was a build-time dep of libXtst. > - libXtst _directly_ requires inputproto at build-time only > - libXtst _directly_ requires libXi at build-time and run-time > > However : > - requiring libXtst at build-time _also_ requires inputproto. > > For most users out there, this would never be a problem since > most Gentoo users always keep build-time deps on their systems. > > The problem arises for people who only keep run-time deps, > usually for binary packages. inputproto being a DEPEND-only dep > of libXtst, binary users will never get inputproto when they > build libfakekey. > > So there were 3 solutions : > > 1) add explicit deps in _all_ packages that DEPEND on libXtst > to _also_ depend on inputproto even if they don't use it at all > (most don't, they just use XTest functions). > > 2) add inputproto to libXtst's DEPEND and RDEPEND > > 3) modify EAPI to add a new *DEPEND variable to cater X's very > special needs. Isn't there a fourth solution? 4) add a USE-flag, say "devel", that, when enabled, allows compiling programs against the package. x11-libs/libXtst would have an RDEPEND like this: RDEPEND="devel? x11-libs/inputproto" Anything wrong with that? ~H
