| 1 |
On 04/10/13 05:41, Michał Górny wrote: |
| 2 |
> On Tue, 9 Apr 2013 18:07:28 -0600 |
| 3 |
> Ryan Hill <dirtyepic@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Tue, 9 Apr 2013 22:24:16 +0200 |
| 6 |
>> Michał Górny <mgorny@g.o> wrote: |
| 7 |
>> |
| 8 |
>>> On Tue, 9 Apr 2013 15:24:10 -0400 |
| 9 |
>>> Mike Frysinger <vapier@g.o> wrote: |
| 10 |
>>> |
| 11 |
>>>> On Tuesday 09 April 2013 01:57:47 Michał Górny wrote: |
| 12 |
>>>>> On Mon, 8 Apr 2013 23:20:28 -0600 Ryan Hill wrote: |
| 13 |
>>>>>> If someone else wants to try and improve the situation, please feel |
| 14 |
>>>>>> free. |
| 15 |
>>>>> Just to be sure -- would you be ok if we tried to inline some |
| 16 |
>>>>> of the eclass code into the ebuilds (future versions/revbumps)? |
| 17 |
>>>> not really. you can still build gcc-2.95 and newer with the current code, |
| 18 |
>>>> but the amount of "tc_version_is_at_least" is fairly low. from time to |
| 19 |
>>>> time, people also create their own gcc ebuild forks which use this eclass |
| 20 |
>>>> either because it's a completely different code base, orit has some serious |
| 21 |
>>>> patches that we aren't interested in carrying, or people want to |
| 22 |
>>>> experiment. current examples: kgcc64 msp430 gcc-apple. we've had other |
| 23 |
>>>> embedded works in the past, as well as hardened ones. |
| 24 |
>>> Then please don't create a fake feeling like you're going to accept |
| 25 |
>>> help to improve the situation. |
| 26 |
>> These are things the eclass has to support and the restraints we have to work |
| 27 |
>> under. Don't throw a snit if you don't like the problem space. |
| 28 |
> My point is that if you'll put everything into the eclass you're never |
| 29 |
> going to improve it. It will be just going from one mess into another, |
| 30 |
> and the ebuilds should never go stable if they don't even have their |
| 31 |
> own phase functions. |
| 32 |
> |
| 33 |
Actually putting everithing in an eclass could make maintenaince easyer |
| 34 |
and faster while providing history of changes. |
| 35 |
My example being mysql (and forks) which use mysql*.eclass. |
| 36 |
Stability for the mysql packages has been good, while maintaining |
| 37 |
_multiple_ versions of them actually useable. |
| 38 |
|
| 39 |
Disclaimer: |
| 40 |
The actual mantainers opinion may be even the opposite of this one, and |
| 41 |
mine may very well be biased, since I'm the one who moved the ebuild in |
| 42 |
the eclasses few years ago. |
Archives