| 1 |
On 19 September 2012 14:01, Matt Turner <mattst88@g.o> wrote: |
| 2 |
> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@g.o> wrote: |
| 3 |
>> On 19 September 2012 03:18, Alec Warner <antarus@g.o> wrote: |
| 4 |
>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@g.o> wrote: |
| 5 |
>>>> Readability is more important, and there I still don't buy the |
| 6 |
>>>> argument that the new syntax is better, and that any gain would |
| 7 |
>>>> outweigh the cost of changing. After all, the existing variables for |
| 8 |
>>>> dependency specification won't disappear, so devs would have to |
| 9 |
>>>> remember both. |
| 10 |
>>> |
| 11 |
>>> I agree it is a con, but is it a blocker? I mean basically any change |
| 12 |
>>> proposed requires know the old way, and the new way..that is how |
| 13 |
>>> changes work... |
| 14 |
>> |
| 15 |
>> Which is why changes need to have clear benefits that outweigh the |
| 16 |
>> costs of change. In this case the benefits are purely cosmetic, so |
| 17 |
>> they don't. Change for change' sake is not worth the effort. |
| 18 |
>> |
| 19 |
>> -- |
| 20 |
>> Cheers, |
| 21 |
>> |
| 22 |
>> Ben | yngwin |
| 23 |
>> Gentoo developer |
| 24 |
>> Gentoo Qt project lead, Gentoo Wiki admin |
| 25 |
>> |
| 26 |
> |
| 27 |
> I'm sorry. Are you reading the same threads that I am? |
| 28 |
|
| 29 |
You've seen me participating in those, so obviously: yes. |
| 30 |
|
| 31 |
> From the other thread ("example conversion of gentoo-x86 current deps |
| 32 |
> to unified dependencies"): |
| 33 |
> |
| 34 |
>> 1) This unifies the existing syntax down into a collapsed form. In |
| 35 |
>> doing so, there are measurable gains across the board for PM |
| 36 |
>> efficiency and rsync alone. |
| 37 |
|
| 38 |
Unifying existing syntax = cosmetic |
| 39 |
|
| 40 |
If collapsing it is beneficial for PM internals, please do so |
| 41 |
internally while hiding it from ebuild devs. |
| 42 |
|
| 43 |
>> 2) In unifying the syntax via reusing our /existing fucking syntax/, |
| 44 |
>> we formalize the adhoc common dependency assignments devs already are |
| 45 |
>> doing in the tree. |
| 46 |
|
| 47 |
Again, cosmetic |
| 48 |
|
| 49 |
>> 3) In moving to a unified syntax, it positions us to easily introduce |
| 50 |
>> new dependency types without introducing more redundancy. Easier to |
| 51 |
>> add new dep types, faster to add new dep types, more efficient in |
| 52 |
>> doing so in comparison to existing approaches, and done in a fashion |
| 53 |
>> that devs can reuse existing conditionals. |
| 54 |
|
| 55 |
Again, cosmetic |
| 56 |
|
| 57 |
Note that adding new dep types only comes up very rarely. |
| 58 |
|
| 59 |
>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. |
| 60 |
>> Meaning you do not need to knee-jerk attack it because of some notion |
| 61 |
>> it's ciaran based/related. |
| 62 |
|
| 63 |
Hm, yeah, so? |
| 64 |
|
| 65 |
> I know you must have seen this (and the rest...). You've participated |
| 66 |
> in that thread. |
| 67 |
|
| 68 |
Indeed. So what made you wonder if I had seen that? |
| 69 |
|
| 70 |
-- |
| 71 |
Cheers, |
| 72 |
|
| 73 |
Ben | yngwin |
| 74 |
Gentoo developer |
| 75 |
Gentoo Qt project lead, Gentoo Wiki admin |
Archives