| 1 |
On 01/06/2013 06:56 AM, Diego Elio Pettenò wrote: |
| 2 |
> I forgot to mention that (a) is what the Ruby team has been doing up |
| 3 |
> to now -- it feels a bit more cumbersome in some cases, but it's |
| 4 |
> definitely easier to spot the problems from the start than finding |
| 5 |
> them months after adding the package of the tree. |
| 6 |
> |
| 7 |
> Especially if you change your mind and decide that you want to add the |
| 8 |
> dependency _after_ the package has been keyworded by half the arches |
| 9 |
> out there. |
| 10 |
> Diego Elio Pettenò — Flameeyes |
| 11 |
> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |
| 12 |
> |
| 13 |
> |
| 14 |
> On Sun, Jan 6, 2013 at 1:50 PM, hasufell <hasufell@g.o> wrote: |
| 15 |
>> I agree with "a". |
| 16 |
>> A problem with "b" is: the user might install one of those "optional |
| 17 |
>> dependencies" later, but that will not trigger a rebuild of the other |
| 18 |
>> package and another run through the test phase. |
| 19 |
>> I would find "c" a bit confusing. |
| 20 |
>> |
| 21 |
>> The most elegant way would probably be to trigger a remerge of package |
| 22 |
>> a, when you want to emerge package b which is also an optional |
| 23 |
>> dependency of package a (in case package a has a test phase ofc). But I |
| 24 |
>> don't see a clean and easy way to do that. |
| 25 |
>> |
| 26 |
>> On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote: |
| 27 |
>>> Go for a. The widest and more consistent the testing, the better. |
| 28 |
>>> |
| 29 |
>>> Otherwise the day after tomorrow you'll get a bug from me that with |
| 30 |
>>> $foo installed, $bar fails tests. |
| 31 |
>>> Diego Elio Pettenò — Flameeyes |
| 32 |
>>> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |
| 33 |
>>> |
| 34 |
>>> |
| 35 |
>>> On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgorny@g.o> wrote: |
| 36 |
>>>> Hello, |
| 37 |
>>>> |
| 38 |
>>>> There are some Python packages which have a bunch of optional tests |
| 39 |
>>>> utilizing external packages. For example, the dev-python/logilab-common |
| 40 |
>>>> runs a few additional tests if dev-python/egenix-mx-base is installed; |
| 41 |
>>>> if the package is not installed, it just skips those tests. |
| 42 |
>>>> |
| 43 |
>>>> Those tests can't be really considered 'heavy' or in any way suggesting |
| 44 |
>>>> use of an additional USE flag. |
| 45 |
>>>> |
| 46 |
>>>> Do you believe that the ebuilds should: |
| 47 |
>>>> |
| 48 |
>>>> a) depend on all optional test dependencies conditionally to USE=test, |
| 49 |
>>>> therefore always requesting the widest (and consistent) testing, |
| 50 |
>>>> |
| 51 |
>>>> b) not depend on the optional test dependencies, resulting in less |
| 52 |
>>>> dependencies for most users but also a bit inconsistent test |
| 53 |
>>>> experience, |
| 54 |
>>>> |
| 55 |
>>>> c) put the optional test dependencies behind an additional USE flag? |
| 56 |
>>>> |
| 57 |
>>>> -- |
| 58 |
>>>> Best regards, |
| 59 |
>>>> Michał Górny |
| 60 |
>>> |
| 61 |
>> |
| 62 |
>> |
| 63 |
> |
| 64 |
This is what I have been doing with my python packages. ('A', that is.) |
| 65 |
|
| 66 |
-- |
| 67 |
-- Matthew Thode (prometheanfire) |
Archives