-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/09/12 06:15 PM, Brian Harring wrote: > > Pardon the belated response; responding to emails that are quick > where possible, but lagging on -dev. Missed this one however... >
No worries, there's a lot going on.. :D >>>> 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. > > It depends on the dep type actually, and how we're viewing those > deps- if they must be complete or not. [ .. Snip! .. ] > > The point I'm trying to make here is that each dep phase should be > authorative; in doing so, you start getting a lot of potential > subsets (DEPEND is a subset of TDEPEND, TDEPEND isn't completely, > but mostly a subset of RDEPEND as RDEPEND is a likely a superset of > DEPEND; PDEPEND is a superset of RDEPEND). > > So... you could do COMMON_DEPEND, COMMON_TDEPEND, COMMON_RDEPEND in > the ebuild. Or you could just use a syntax form that allows you > to directly inline that up front, rather than having to muck around > w/ intermediate vars. > ... I think what you've just described here might be where the primary difference in thinking is for most of us, between moving to DEPENDENCIES and keeping the current *DEPENDs -- to me, from an ebuild writer's perspective, the *DEPENDS -shouldn't- be authoritative. IE, instead of thinking of PDEPEND as a superset of RDEPEND I consider they are two separate sets, which should not intersect, and are unioned together to form the full set of runtime dependencies. IE: FULL_RUNTIME_DEPEND="$RDEPEND $PDEPEND" somewhere inside portage, if portage actually needed it this way. And I see this as how many of the other proposed new *DEPENDs would work too, ie, they are a refined subset of the bigger sets and should not intersect with the 'parent' *DEPEND that was used instead on older EAPIs. So if this were to change, it might make sense (as Duncan i think pointed out in his response to this message), to a debate on whether or not ebuilds must specify an authoritative list for each dep phase. (I haven't read through PMS but I'm going to assume that it doesn't specify this anywhere yet--and if it does, i'm sure Ciaran or someone will quote it in response :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrKKsACgkQ2ugaI38ACPBA9wD/a+XVf2g9s6dcpW1513aXQpYV tK94QdLkax0Hs6tKFqcA/0+v6oFON2Bd3hedv9DHg7N42NNvtTKK6sOw18OpL0aO =frmC -----END PGP SIGNATURE-----
