From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
Date: Mon, 1 Oct 2012 00:23:52 +0000 (UTC) [thread overview]
Message-ID: <pan.2012.10.01.00.23.53@cox.net> (raw)
In-Reply-To: 20120930221518.GG2180@localhost
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
next prev parent reply other threads:[~2012-10-01 0:25 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 11:45 [gentoo-dev] Unified DEPENDENCIES concept Ciaran McCreesh
2012-09-07 12:29 ` Michał Górny
2012-09-07 12:36 ` Ciaran McCreesh
2012-09-07 14:23 ` Michał Górny
2012-09-07 14:53 ` Ciaran McCreesh
2012-09-07 15:02 ` Michał Górny
2012-09-07 15:07 ` Ciaran McCreesh
2012-09-07 15:16 ` Michał Górny
2012-09-07 15:25 ` Wulf C. Krueger
2012-09-07 14:50 ` Ian Stakenvicius
2012-09-07 14:58 ` Ciaran McCreesh
2012-09-07 15:46 ` Alexis Ballier
2012-09-07 16:03 ` Michał Górny
2012-09-07 16:11 ` Ian Stakenvicius
2012-09-07 16:28 ` Michael Mol
2012-09-07 16:34 ` Ciaran McCreesh
2012-09-07 16:40 ` "Paweł Hajdan, Jr."
2012-09-07 16:47 ` Ciaran McCreesh
2012-09-07 17:40 ` Alexis Ballier
2012-09-07 18:21 ` Michał Górny
2012-09-07 19:59 ` Alexis Ballier
2012-09-07 20:10 ` Michał Górny
2012-09-07 20:14 ` Ian Stakenvicius
2012-09-11 2:16 ` Brian Harring
2012-09-13 19:18 ` Kent Fredric
2012-09-13 22:17 ` Brian Harring
2012-09-15 11:06 ` Kent Fredric
2012-09-15 20:33 ` Brian Harring
2012-09-15 22:03 ` Michał Górny
2012-09-16 1:20 ` [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies Brian Harring
2012-09-16 2:39 ` Diego Elio Pettenò
2012-09-16 7:39 ` Ben de Groot
2012-09-16 13:15 ` Brian Harring
2012-09-18 22:51 ` Matt Turner
2012-09-19 4:22 ` Ben de Groot
2012-09-19 10:59 ` [gentoo-dev] " Duncan
2012-09-19 13:09 ` Michael Orlitzky
2012-09-19 13:16 ` Ian Stakenvicius
2012-09-30 22:15 ` Brian Harring
2012-10-01 0:23 ` Duncan [this message]
2012-10-02 17:47 ` Ian Stakenvicius
2012-10-03 4:00 ` Ben de Groot
2012-10-07 14:09 ` [gentoo-dev] " Steven J. Long
2012-09-16 7:56 ` [gentoo-dev] " Michał Górny
2012-09-16 11:10 ` Brian Harring
2012-09-16 11:21 ` Michał Górny
2012-09-16 11:49 ` Brian Harring
2012-09-16 12:02 ` Michał Górny
2012-09-16 13:38 ` Brian Harring
2012-09-07 16:10 ` [gentoo-dev] Unified DEPENDENCIES concept Ciaran McCreesh
2012-09-07 16:53 ` Zac Medico
2012-09-07 16:58 ` Ciaran McCreesh
2012-09-07 17:02 ` Ian Stakenvicius
2012-09-07 17:40 ` Zac Medico
2012-09-07 17:58 ` Ian Stakenvicius
2012-09-07 18:18 ` Zac Medico
2012-09-07 18:23 ` Ciaran McCreesh
2012-09-07 18:23 ` Zac Medico
2012-09-07 18:23 ` Michał Górny
2012-09-07 18:31 ` Ciaran McCreesh
2012-09-07 18:46 ` Michał Górny
2012-09-07 18:52 ` Ciaran McCreesh
2012-09-07 19:11 ` Michał Górny
2012-09-07 19:13 ` Ciaran McCreesh
2012-09-07 19:21 ` Michał Górny
2012-09-07 19:25 ` Ciaran McCreesh
2012-09-07 20:07 ` Michał Górny
2012-09-07 20:15 ` Ciaran McCreesh
2012-09-07 20:08 ` Ian Stakenvicius
2012-09-07 20:14 ` Ciaran McCreesh
2012-09-07 20:28 ` Ian Stakenvicius
2012-09-07 20:40 ` Ciaran McCreesh
2012-09-07 19:42 ` Ian Stakenvicius
2012-09-07 17:31 ` Zac Medico
2012-09-07 16:12 ` "Paweł Hajdan, Jr."
2012-09-07 16:43 ` Michał Górny
2012-09-07 22:55 ` Michael Orlitzky
2012-09-08 6:43 ` Ciaran McCreesh
2012-09-08 13:01 ` Michael Orlitzky
2012-09-08 7:27 ` Michał Górny
2012-09-08 1:02 ` Patrick Lauer
2012-09-09 3:32 ` Matt Turner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2012.10.01.00.23.53@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox