[gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies

[Duncan]

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