| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 07/09/12 04:10 PM, Michał Górny wrote: |
| 5 |
> On Fri, 7 Sep 2012 16:59:48 -0300 Alexis Ballier |
| 6 |
> <aballier@g.o> wrote: |
| 7 |
> |
| 8 |
>> On Fri, 7 Sep 2012 20:21:03 +0200 Michał Górny |
| 9 |
>> <mgorny@g.o> wrote: |
| 10 |
>> |
| 11 |
>>> On Fri, 7 Sep 2012 14:40:25 -0300 Alexis Ballier |
| 12 |
>>> <aballier@g.o> wrote: |
| 13 |
>>> |
| 14 |
>>>> On Fri, 7 Sep 2012 18:03:51 +0200 Michał Górny |
| 15 |
>>>> <mgorny@g.o> wrote: |
| 16 |
>>>> |
| 17 |
>>>>> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier |
| 18 |
>>>>> <aballier@g.o> wrote: |
| 19 |
>>>>> |
| 20 |
>>>>>> I actually do like the concept but I'm not sure we can |
| 21 |
>>>>>> reach consensus about '*DEPEND vs DEPENDENCIES'; a |
| 22 |
>>>>>> possibility to get people used to it could be to have two |
| 23 |
>>>>>> parallel EAPIs, like 6 and 6-dependencies, where the |
| 24 |
>>>>>> former will keep the old style and the latter use |
| 25 |
>>>>>> DEPENDENCIES. |
| 26 |
>>>>> |
| 27 |
>>>>> With eclasses supporting both of them? That's more than |
| 28 |
>>>>> crazy. |
| 29 |
>>>> |
| 30 |
>>>> depstr=cat/foo |
| 31 |
>>>> |
| 32 |
>>>> case $EAPI in *-dependencies) DEPENDENCIES="build+run: |
| 33 |
>>>> $depstr";; *) DEPEND="$depstr" RDEPEND="$depstr";; esac |
| 34 |
>>> |
| 35 |
>>> Yes, we have many eclasses where this is actually the only |
| 36 |
>>> expected result. Maybe start with python.eclass, that should be |
| 37 |
>>> quite an extreme example. |
| 38 |
>>> |
| 39 |
>> |
| 40 |
>> Reference needed. You probably didn't even think more than 2 |
| 41 |
>> seconds before making this claim about python.eclass, because it |
| 42 |
>> is not particularly hard. |
| 43 |
> |
| 44 |
> Hmm, didn't it used to support having python as DEPEND only? |
| 45 |
> |
| 46 |
> In any case, I'm thinking more of that line. Eclasses which |
| 47 |
> sometimes add RDEP+DEP, sometimes DEP only, and sometimes do even |
| 48 |
> crazier things. |
| 49 |
> |
| 50 |
|
| 51 |
Is there anything in particular in the spec/proposal for DEPENDENCIES |
| 52 |
that would exclude the addition of individual "build: app-cat/myatom" |
| 53 |
"run: app-cat/myatom" deps by an eclass or eclasses? I know the |
| 54 |
"goal" here is to make things atom-centric, but I can't see an |
| 55 |
implementation ever working of this that wouldn't permit the "pile-on" |
| 56 |
of additional entries of different (or even the same) roles on |
| 57 |
identical or near-identical atoms. |
| 58 |
|
| 59 |
-----BEGIN PGP SIGNATURE----- |
| 60 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 61 |
|
| 62 |
iF4EAREIAAYFAlBKVZkACgkQ2ugaI38ACPAdAwEAlGthSTR/jor93qpclC5Gl+Sl |
| 63 |
82mjHm3ZObOC8Btf+SYA/AxaxCfHuWXoYKj5Ryo9CKna/7cdc1sUoV0fvacO9fja |
| 64 |
=AoSy |
| 65 |
-----END PGP SIGNATURE----- |
Archives