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 00:07:57
In Reply to: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal by Brian Harring
1 On Sun, 30 Sep 2012 14:42:14 -0700
2 Brian Harring <ferringb@×××××.com> wrote:
3 > Reality is, our current form can handle deps generally fine- what you
4 > label as trivial is the vast majority- I argue effectively all.
6 We could do away with half of the current feature set if we were only
7 interested in making things nice for the "vast majority" of cases...
9 > This statement of yours however is fairly disenguous; label behaviour
10 > when nested suffers the same mental parsing oddity (wait, we're in
11 > build context, and this is test? Wtf happens there?).
13 No, label behaviour is local, and scope independent.
15 > Means that 'blah' target doesn't show up. Which is the *same* as
16 > what happens if someone did thus in our existing syntax:
17 >
18 > x? ( !x? ( blah ) )
19 >
20 > Worth noting, you didn't ban that from exherbo; you left that to sort
21 > itself out, same as I'm doing for dep:blah flags. Were I punching
22 > below the belt, the word 'hypocritical' would likely be involved.
24 That's "not fixing an existing screw-up", which is not the same at all
25 as "adding a new screw-up".
27 > > The second is that it starts the conceptual shift from "cat/pkg is a
28 > > build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is
29 > > required for build and run".
30 >
31 > Fairly weak argument at best; you're claiming that via labels,
32 > "contextually they know it's these deps" in comparison to via
33 > dep:build "contextually they know it's exposed only in build".
34 >
35 > Same difference.
37 It's rather a big deal now that we have := dependencies.
39 > > No, I want something where things that are different look different.
40 > > Dependency types are nothing like use flags, so they shouldn't look
41 > > the same.
42 >
43 > I'll buy that argument, and to some degree- agree.
44 >
45 > I just view that as academic wankery without real world gain.
46 >
47 > So like I said, academically possible, but
48 > pragmatically/unrealistically unneded.
50 Labels are almost as easy to implement as your "filtering" model, and
51 they come with the benefit of a better syntax for developers. Even if
52 labels are noticably more work to implement, which I'm not convinced is
53 the case, it's worth paying that price a couple of times in package
54 manglers rather than having developers pay the price of worse syntax in
55 thousands of ebuilds. Filtering is a whole new mechanism anyway.
57 But here's the thing: when you sell something as "pragmatic", what
58 you're really saying is "it's wrong, I know it's wrong, and I'm going
59 to pretend that wrong is a good thing". Getting it wrong should be
60 something you do only after you're sure you can't afford get it right;
61 it shouldn't be something you're proud of.
63 > In my proposal, I am addressing labels; will fold in your claims, but
64 > those claims basically are shit- however, if you *did* find a
65 > conflicting nested example that wasn't contrived, preferablly
66 > multiple, I'd like those examples so I can include them into the
67 > proposal (give labels a fair hand, basically).
69 You already have an example in your proposal, in the form of mplayer's
70 X? ( ) dependencies.
72 But that's missing the point. Even if you pretend complicated
73 dependencies don't exist, labels are still by far the better proposal.
74 Your argument boils down to "it's more pragmatic to do a quick and dirty
75 implementation in Portage and thus force the technical debt onto every
76 single ebuild than it is to do it cleanly".
78 --
79 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>