Gentoo Archives: gentoo-pms

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Brian Harring <ferringb@×××××.com>
Cc: gentoo-pms@l.g.o, gentoo-dev@l.g.o
Subject: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
Date: Mon, 01 Oct 2012 07:16:48
In Reply to: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal by Brian Harring
1 On Sun, 30 Sep 2012 16:56:56 -0700
2 Brian Harring <ferringb@×××××.com> wrote:
3 > On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote:
4 > > But here's the thing: when you sell something as "pragmatic", what
5 > > you're really saying is "it's wrong, I know it's wrong, and I'm
6 > > going to pretend that wrong is a good thing". Getting it wrong
7 > > should be something you do only after you're sure you can't afford
8 > > get it right; it shouldn't be something you're proud of.
9 >
10 > No, when I say pragmatic, what I'm actually saying is that people who
11 > can't focus on cost/gain, by large, haven't had real jobs (else they
12 > would've had that perfectionism/decreasing gains ground out of them
13 > sooner or later), and are spending their time whacking off chasing a
14 > mythical 'perfect' solution.
16 I don't know whether you're aware of this, but a small number (cost per
17 ebuild) multiplied by a big number (lots of ebuilds) can be larger than
18 a medium sized number (cost of implementing a good solution). I realise
19 this is a sophisticated technique I'm using here, but I assure you
20 multiplication has been used in some industries for a few years now.
22 > Academic wankery, is the short version. You're good at technical,
23 > but you frequently do the academic wanking crap which leads to things
24 > dead-ending... plus wasted time because to you, 'pragmatic' is a
25 > dirty word (compromise? Heaven forbid!).
27 Or looking at it another way: you're so eager to deliver a "compromise"
28 and a "pragmatic" solution (at the expense of ebuild writers
29 everywhere) that you immediately rule out a "good" solution just so
30 you can push the virtues of doing it wrong. Doing it wrong should be a
31 last resort, not something you look to do at any given opportunity.
33 > > > In my proposal, I am addressing labels; will fold in your claims,
34 > > > but those claims basically are shit- however, if you *did* find a
35 > > > conflicting nested example that wasn't contrived, preferablly
36 > > > multiple, I'd like those examples so I can include them into the
37 > > > proposal (give labels a fair hand, basically).
38 > >
39 > > You already have an example in your proposal, in the form of
40 > > mplayer's X? ( ) dependencies.
41 >
42 > I said nested conflicting labels. Meaning
43 > "build: x? ( dar run: blah )"
44 >
45 > which isn't the case for any of mplayer deps.
47 x? ( build: a run: b ) *is* nested "conflicting".
49 You're still failing to understand the point of labels parsing rules,
50 though: the point is to make uses like the above well defined and
51 consistent.
53 > We are not exherbo- we do not have the luxury of chucking out syntax
54 > and pulling NIH renaming of things for shits and giggles. Especially
55 > if the new syntax is directly translatable into a tweak of our
56 > existing syntax (a tweak that we should do anyways- recall I built
57 > this off of fixing USE_EXPAND).
59 This isn't chucking out syntax. It's augmenting existing syntax. What
60 you're doing is trying to shove something new onto an existing syntax
61 which doesn't fit it.
63 You should know this from REQUIRED_USE: that's a perfect example of
64 going too far to reuse existing syntax.
66 > Your argument boils down to "it's not labels, ignore that it's
67 > aesthetic knob polishing (you can do the same w/ our existent
68 > syntax, thus the analogy of waxing it I truly mean), use labels
69 > because I'll berate you incessently till you accede".
71 It's about giving ebuild developers a good format to work with. That
72 sort of thing matters. There are a lot of ebuilds and not many package
73 manglers.
75 --
76 Ciaran McCreesh


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Brian Harring <ferringb@×××××.com>