Le 28/12/2009 22:04, Fabio Erculiani a écrit : > On Mon, Dec 28, 2009 at 9:51 PM, David Leverton > <levert...@googlemail.com> 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. Solution #1 is error prone. If we "fix" ebuilds now, new ebuilds might pop up later with "broken" dependencies. No go. Solution #3 really isn't for me. I tried getting near PMS and I got bit. If anyone wants to do this, I'll help, but I won't do this on my own. So we went with solution #2. Yes, it does add nasty little headers on a binary distribution, but that was a far better compromise than any of the other 2 solutions. Really, the correct solution (please _listen_ and _trust_ me on this) is to add a new dependency variable to EAPI to correctly describe how X headers and libs really work. That's solution #3. I agree with you, pulling protos in both DEPEND and RDEPEND is a hack, but it's *much* better than the other alternatives. Rémi [1] This file is now part of libXi, but the problem has now shifted to XI.h, so it's still going to be the exact same problem today, but for the sake of simplicity, I'll keep it short.
