| 1 |
On 1.9.2011 14.31, Michał Górny wrote: |
| 2 |
> On Thu, 01 Sep 2011 14:02:11 +0300 |
| 3 |
> Petteri Räty <betelgeuse@g.o> wrote: |
| 4 |
> |
| 5 |
>> On 1.9.2011 13.51, Michał Górny wrote: |
| 6 |
>>> On Thu, 01 Sep 2011 13:44:47 +0300 |
| 7 |
>>> Petteri Räty <betelgeuse@g.o> wrote: |
| 8 |
>>> |
| 9 |
>>>> On 1.9.2011 12.03, Michał Górny wrote: |
| 10 |
>>>>> Hello, |
| 11 |
>>>>> |
| 12 |
>>>>> A quick idea. Right now eclasses sometimes do API changes and |
| 13 |
>>>>> start yelling at users merging ebuilds using outdates APIs. This |
| 14 |
>>>>> often means users start filling bugs about outdated ebuilds |
| 15 |
>>>>> requiring maintainers either to ignore that or start updating old |
| 16 |
>>>>> ebuilds retroactively. |
| 17 |
>>>>> |
| 18 |
>>>>> Maybe we should add some kind of devqawarn() function to |
| 19 |
>>>>> eutils.eclass, which would trigger special QA warnings only when |
| 20 |
>>>>> ebuild is merged by a developer? This could be triggered e.g. by |
| 21 |
>>>>> some kind of voluntary make.conf setting. |
| 22 |
>>>>> |
| 23 |
>>>> |
| 24 |
>>>> What's wrong with eqawarn that's already provided by eutils? |
| 25 |
>>> |
| 26 |
>>> The first paragraph? |
| 27 |
>>> |
| 28 |
>> |
| 29 |
>> Have Portage defaults so that users only see if them if they read the |
| 30 |
>> merge logs and then developer profiles can set the settings to log |
| 31 |
>> them? |
| 32 |
> |
| 33 |
> 1) that's changing existing behavior, |
| 34 |
> 2) what with non-portage users? |
| 35 |
> |
| 36 |
|
| 37 |
1) eqawarn == devqawarn. I don't see a reason to come up with a new |
| 38 |
function just to avoid changing Portage configuration. |
| 39 |
|
| 40 |
2) How messages from each e* function is shown is left to the package |
| 41 |
manager to decide. |
| 42 |
|
| 43 |
One thing to note is that we should get eqawarn into the next EAPI. |
| 44 |
|
| 45 |
Regards, |
| 46 |
Petteri |
Archives