Gentoo Archives: gentoo-dev

From: Matt Turner <mattst88@g.o>
To: Ben de Groot <yngwin@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
Date: Wed, 19 Sep 2012 06:03:18
Message-Id: CAEdQ38GzkHjqoO19fWO-qUQse2ieCYoZ49So_3Osr=SnU=v4Sw@mail.gmail.com
In Reply to: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal by Ben de Groot
1 On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@g.o> wrote:
2 > On 19 September 2012 03:18, Alec Warner <antarus@g.o> wrote:
3 >> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@g.o> wrote:
4 >>> Readability is more important, and there I still don't buy the
5 >>> argument that the new syntax is better, and that any gain would
6 >>> outweigh the cost of changing. After all, the existing variables for
7 >>> dependency specification won't disappear, so devs would have to
8 >>> remember both.
9 >>
10 >> I agree it is a con, but is it a blocker? I mean basically any change
11 >> proposed requires know the old way, and the new way..that is how
12 >> changes work...
13 >
14 > Which is why changes need to have clear benefits that outweigh the
15 > costs of change. In this case the benefits are purely cosmetic, so
16 > they don't. Change for change' sake is not worth the effort.
17 >
18 > --
19 > Cheers,
20 >
21 > Ben | yngwin
22 > Gentoo developer
23 > Gentoo Qt project lead, Gentoo Wiki admin
24 >
25
26 I'm sorry. Are you reading the same threads that I am?
27
28 From the other thread ("example conversion of gentoo-x86 current deps
29 to unified dependencies"):
30
31 > 1) This unifies the existing syntax down into a collapsed form. In
32 > doing so, there are measurable gains across the board for PM
33 > efficiency and rsync alone.
34 >
35 > 2) In unifying the syntax via reusing our /existing fucking syntax/,
36 > we formalize the adhoc common dependency assignments devs already are
37 > doing in the tree.
38 >
39 > 3) In moving to a unified syntax, it positions us to easily introduce
40 > new dependency types without introducing more redundancy. Easier to
41 > add new dep types, faster to add new dep types, more efficient in
42 > doing so in comparison to existing approaches, and done in a fashion
43 > that devs can reuse existing conditionals.
44 >
45 > 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
46 > Meaning you do not need to knee-jerk attack it because of some notion
47 > it's ciaran based/related.
48
49 I know you must have seen this (and the rest...). You've participated
50 in that thread.

Replies