> On 30/09/12 06:15 PM, Brian Harring wrote:
>
>>>>> yngwin has a point that I've not seen addressed.
>>>>>
>>>>> What /is/ wrong with the whole CDEPEND intermediate var idea?
>>>>>
>>>>
>>>> The problem appears as we introduce more DEPEND variables
>>>> (which is what prompted the proposal, IIRC). If we have
>>>> ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some
>>>> (i.e. not total) sharing going on then the COMMON_DEPEND
>>>> pattern starts to fall apart. You potentially need,
>>>>
>>>> AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND
>>>> ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND
>>>> (COMMON_DEPEND)
>>>>
>>>> This obviously gets worse as more DEPEND vars are introduced.
>>>>
>>>
>>> Well not really, no -- the additional *DEPENDs that are being
>>> proposed (or at least mentioned) for new EAPI will either remove
>>> atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so
>>> tersely that a COMMON_DEPEND or other intermediate variable won't
>>> really be necessary for them.
Another thing I wanted to point out is that those "potential" extra
variables are not needed in practice. We already have 98% of the tree
(if I got the previously mentioned stats right) that does fine with
just one or two ({R,}DEPEND). The majority of that other 2% needs just
one more variable. There may be corner cases where more vars would be
needed, but those will never be more than a few ebuilds.
It's just not worth it to completely change the way we do things (or
use two systems in parallel) just for a few ebuilds that would
significantly benefit.
If we were a new distro and designing our ebuild format from scratch,
then yes, I would say your proposal has merit. But we aren't. We have
hundreds of people and tens of thousands of ebuilds using *DEPEND just
fine. There are no big problems, only corner-cases. We're not talking
about incremental improvements either (such as was the case e.g. with
use deps).
Let's just keep things simple, and refrain from "fixing" what isn't broken.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
