Brian Harring posted on Sun, 30 Sep 2012 15:15:18 -0700 as excerpted: > The point I'm trying to make here is that each dep phase should be > authorative; in doing so, you start getting a lot of potential subsets > (DEPEND is a subset of TDEPEND, TDEPEND isn't completely, but mostly a > subset of RDEPEND as RDEPEND is a likely a superset of DEPEND; PDEPEND > is a superset of RDEPEND). > > So... you could do COMMON_DEPEND, COMMON_TDEPEND, COMMON_RDEPEND in the > ebuild. Or you could just use a syntax form that allows you to directly > inline that up front, rather than having to muck around w/ intermediate > vars.
Thanks /very/ much! You said you weren't sure you were being clear, but this is the first time I've /really/ understood what must surely be the root, at any reasonable level at all. Let me see if I've got it right: Yes, in some ways all we're dealing with here is "optics", but the _problem_ is that with the proposed proliferation in detailed depend- types, what is now a simple CDEPEND and thus conceptually easy to handle, breaks into 10/20/50/whatever-large-number different shards, and what's conceptually easy to handle /now/ becomes many many times more difficult to handle, both conceptually for package maintainers and practically for iterative resolution in the PMs, due to the interplay of all the resulting *CDEPENDs. The proposed solution to that explosion in conceptual complexity not only changes the "optics", but by making most of those detail-depend-types absolute/authoritative, allows both package managers (the programs, machine) and package maintainers (the humans) to consider each depend- type separately, thus decreasing both conceptual complexity to a once again manageable level for package maintainers (humans), and practical complexity for package managers (machine), increasing efficiency, reducing resolution time and probably eventually memory/installed-db/ cache size as well. Of course now I better understand Ciaran's argument for labels as well, since it would extend the absolute/authoritative principle even further, into the actual deps specification method in ebuilds/eclasses, thereby reducing conceptual context load even further via more explicitly absolute deps at the local level. But like you, in practice I don't see that going anywhere in gentoo, in the near/short-intermediate future, primarily due to political realities, but practically, also due to the conceptual leap it'd require from devs (as Ciaran himself points out in response to your statistical analysis of exherbo's repo, former gentoo devs simply don't tend to take advantage of this aspect of labels in exherbo either; the conceptual leap is in practice simply too much). Thus, while academically, his label approach is arguably better in terms of efficiency of absolutes, in practice, there's little or no difference between how it's used, and how your filtering approach will be used. Further, given the conceptual distance between labels and gentoo's current approach, with filters falling in between and political reality, the pragmatic filters approach at least has /some/ chance of passing the dev-debate stage and being approved, implemented and actually available for use in something like a reasonable timeframe (say EAPI-6, in a year's time, a bit more for actual in-tree use, given the historic EAPI-a-year processing). But exherbo style labels support altho academically better, given political reality, in all likelihood would take at least 2-3 years to pass and be usable in-tree. And even then, its practical use as demonstrated in exherbo wouldn't take advantage of the differences for another couple years after that, at least. Given that, having use of the useful pragmatic approach in a year's time or so seems best, as opposed to an arguably (as you've pointed out, no practical demonstration of it in exherbo yet, at least that you've been able to find) more academically ideal approach in three, without any real benefit over the pragmatic for five or more. >> Besides, this isn't actually a -problem- as there's nothing which >> really requires one to use such helpers; ebuild writers just, well, >> can. :) > > Getting to this point; yes, people could hack around it manually. Pretty > sure that hasn't been in doubt. That's clearer now. Yes, people could continue to hack around it via CDEPENDS, etc. But the number of common vars (or alternative RDEPEND="$DEPEND ..." assignments) and the resulting conceptual load on the human maintainer is set to increase exponentially as the number of depend-types increases linearly. At some point it's just no longer practically maintainable, and the whole process breaks down. What the single dependencies variable aims to do in both the filtering and labels forms is prevent that ultimate conceptual overload and resulting process breakdown by allowing direct compound assignments, thus eliminating the intermediate assignments and their exponential proliferation. Thanks again, Brian. Much clearer now, indeed, at least for me, and presumably for others who previously had the same problem I was having. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
