On 19 September 2012 14:01, Matt Turner <[email protected]> wrote:
> On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <[email protected]> wrote:
>> On 19 September 2012 03:18, Alec Warner <[email protected]> wrote:
>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <[email protected]> wrote:
>>>> Readability is more important, and there I still don't buy the
>>>> argument that the new syntax is better, and that any gain would
>>>> outweigh the cost of changing. After all, the existing variables for
>>>> dependency specification won't disappear, so devs would have to
>>>> remember both.
>>>
>>> I agree it is a con, but is it a blocker? I mean basically any change
>>> proposed requires know the old way, and the new way..that is how
>>> changes work...
>>
>> Which is why changes need to have clear benefits that outweigh the
>> costs of change. In this case the benefits are purely cosmetic, so
>> they don't. Change for change' sake is not worth the effort.
>>
>> --
>> Cheers,
>>
>> Ben | yngwin
>> Gentoo developer
>> Gentoo Qt project lead, Gentoo Wiki admin
>>
>
> I'm sorry. Are you reading the same threads that I am?
You've seen me participating in those, so obviously: yes.
> From the other thread ("example conversion of gentoo-x86 current deps
> to unified dependencies"):
>
>> 1) This unifies the existing syntax down into a collapsed form. In
>> doing so, there are measurable gains across the board for PM
>> efficiency and rsync alone.
Unifying existing syntax = cosmetic
If collapsing it is beneficial for PM internals, please do so
internally while hiding it from ebuild devs.
>> 2) In unifying the syntax via reusing our /existing fucking syntax/,
>> we formalize the adhoc common dependency assignments devs already are
>> doing in the tree.
Again, cosmetic
>> 3) In moving to a unified syntax, it positions us to easily introduce
>> new dependency types without introducing more redundancy. Easier to
>> add new dep types, faster to add new dep types, more efficient in
>> doing so in comparison to existing approaches, and done in a fashion
>> that devs can reuse existing conditionals.
Again, cosmetic
Note that adding new dep types only comes up very rarely.
>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>> Meaning you do not need to knee-jerk attack it because of some notion
>> it's ciaran based/related.
Hm, yeah, so?
> I know you must have seen this (and the rest...). You've participated
> in that thread.
Indeed. So what made you wonder if I had seen that?
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
