| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 30/09/12 06:15 PM, Brian Harring wrote: |
| 5 |
> |
| 6 |
> Pardon the belated response; responding to emails that are quick |
| 7 |
> where possible, but lagging on -dev. Missed this one however... |
| 8 |
> |
| 9 |
|
| 10 |
No worries, there's a lot going on.. :D |
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
>>>> yngwin has a point that I've not seen addressed. |
| 15 |
>>>> |
| 16 |
>>>> What /is/ wrong with the whole CDEPEND intermediate var idea? |
| 17 |
>>>> |
| 18 |
>>> |
| 19 |
>>> The problem appears as we introduce more DEPEND variables |
| 20 |
>>> (which is what prompted the proposal, IIRC). If we have |
| 21 |
>>> ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some |
| 22 |
>>> (i.e. not total) sharing going on then the COMMON_DEPEND |
| 23 |
>>> pattern starts to fall apart. You potentially need, |
| 24 |
>>> |
| 25 |
>>> AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND |
| 26 |
>>> ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND |
| 27 |
>>> (COMMON_DEPEND) |
| 28 |
>>> |
| 29 |
>>> This obviously gets worse as more DEPEND vars are introduced. |
| 30 |
>>> |
| 31 |
>> |
| 32 |
>> Well not really, no -- the additional *DEPENDs that are being |
| 33 |
>> proposed (or at least mentioned) for new EAPI will either remove |
| 34 |
>> atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so |
| 35 |
>> tersely that a COMMON_DEPEND or other intermediate variable won't |
| 36 |
>> really be necessary for them. |
| 37 |
> |
| 38 |
> It depends on the dep type actually, and how we're viewing those |
| 39 |
> deps- if they must be complete or not. [ .. Snip! .. ] |
| 40 |
> |
| 41 |
> The point I'm trying to make here is that each dep phase should be |
| 42 |
> authorative; in doing so, you start getting a lot of potential |
| 43 |
> subsets (DEPEND is a subset of TDEPEND, TDEPEND isn't completely, |
| 44 |
> but mostly a subset of RDEPEND as RDEPEND is a likely a superset of |
| 45 |
> DEPEND; PDEPEND is a superset of RDEPEND). |
| 46 |
> |
| 47 |
> So... you could do COMMON_DEPEND, COMMON_TDEPEND, COMMON_RDEPEND in |
| 48 |
> the ebuild. Or you could just use a syntax form that allows you |
| 49 |
> to directly inline that up front, rather than having to muck around |
| 50 |
> w/ intermediate vars. |
| 51 |
> |
| 52 |
|
| 53 |
... I think what you've just described here might be where the primary |
| 54 |
difference in thinking is for most of us, between moving to |
| 55 |
DEPENDENCIES and keeping the current *DEPENDs -- to me, from an ebuild |
| 56 |
writer's perspective, the *DEPENDS -shouldn't- be authoritative. IE, |
| 57 |
instead of thinking of PDEPEND as a superset of RDEPEND I consider |
| 58 |
they are two separate sets, which should not intersect, and are |
| 59 |
unioned together to form the full set of runtime dependencies. IE: |
| 60 |
FULL_RUNTIME_DEPEND="$RDEPEND $PDEPEND" somewhere inside portage, if |
| 61 |
portage actually needed it this way. |
| 62 |
|
| 63 |
And I see this as how many of the other proposed new *DEPENDs would |
| 64 |
work too, ie, they are a refined subset of the bigger sets and should |
| 65 |
not intersect with the 'parent' *DEPEND that was used instead on older |
| 66 |
EAPIs. |
| 67 |
|
| 68 |
So if this were to change, it might make sense (as Duncan i think |
| 69 |
pointed out in his response to this message), to a debate on whether |
| 70 |
or not ebuilds must specify an authoritative list for each dep phase. |
| 71 |
(I haven't read through PMS but I'm going to assume that it doesn't |
| 72 |
specify this anywhere yet--and if it does, i'm sure Ciaran or someone |
| 73 |
will quote it in response :) |
| 74 |
-----BEGIN PGP SIGNATURE----- |
| 75 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 76 |
|
| 77 |
iF4EAREIAAYFAlBrKKsACgkQ2ugaI38ACPBA9wD/a+XVf2g9s6dcpW1513aXQpYV |
| 78 |
tK94QdLkax0Hs6tKFqcA/0+v6oFON2Bd3hedv9DHg7N42NNvtTKK6sOw18OpL0aO |
| 79 |
=frmC |
| 80 |
-----END PGP SIGNATURE----- |
Archives