| 1 |
On 31 August 2013 00:37, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Hello, all. |
| 3 |
> |
| 4 |
> After a few days of thinking, discovering and working, here it is. |
| 5 |
> The first working draft of new git eclass codenamed 'git-r3'. |
| 6 |
> |
| 7 |
> First of all, the name is not final. I'm open to ideas. I'm open to |
| 8 |
> naming it 'git-r1' to put it in line with my other -r1 eclasses :). |
| 9 |
> I'd definitely like to avoid 'git-3' though, since that version-like |
| 10 |
> naming was a mistake as almost-'python-2' eclass shown. |
| 11 |
> |
| 12 |
> Secondly, it's not even final that there will be a new eclass. Most |
| 13 |
> likely I will commit it as a new eclass since that way is easier for us |
| 14 |
> but if you prefer I may try to get it and git-2 more API-friendly |
| 15 |
> and work on making it a almost-drop-in replacement. Since, after all, |
| 16 |
> internals have actually changed much more than the API. |
| 17 |
> |
| 18 |
|
| 19 |
Hi, |
| 20 |
|
| 21 |
I have no capacity to review the eclass right now (although I promise |
| 22 |
I will soon) |
| 23 |
but I was wondering why the whole eclass is inside the " if [[ ! |
| 24 |
${_GIT_R3} ]] " block. |
| 25 |
Is it so you can avoid inheriting the same eclass twice? I haven't |
| 26 |
seen that before |
| 27 |
so I was wondering if that's the only reason. If yes, then maybe this |
| 28 |
needs to be solved in PM scope instead? |
| 29 |
As in, prevent portage from inheriting the same eclass twice instead |
| 30 |
of handling this case in the eclass itself. |
| 31 |
|
| 32 |
-- |
| 33 |
Regards, |
| 34 |
Markos Chandras - Gentoo Linux Developer |
| 35 |
http://dev.gentoo.org/~hwoarang |
Archives