1 |
On Fri, 16 Sep 2011 09:54:47 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
> > This is a build-against dependency, and it's best expressed either |
4 |
> > by its own BADEPEND, or (because it's apparently now possible, and |
5 |
> > because otherwise we'd end up with six or seven *DEPEND variables) |
6 |
> > by switching to something like DEPENDENCIES with a build-against |
7 |
> > label. |
8 |
> |
9 |
> Please do not wreak exheres into Gentoo. The current variable forms |
10 |
> are complex enough; there is no reason to put even more logic into |
11 |
> the parser. And yes, it's better to have 7 *DEPEND variables than one |
12 |
> more magical, conditional thingie in the 'Dependencies' section. |
13 |
|
14 |
From feedback so far, I think you're in the minority on that (at least |
15 |
from people who have expressed an opinion), and that more people have |
16 |
come out in favour of a single unified variable (not necessarily with |
17 |
exactly the same syntax as exheres-0). |
18 |
|
19 |
*shrug* I don't really mind about the syntax either way, and I suspect |
20 |
that'll come down to a Council decision. I do care about getting the |
21 |
exact definitions of what the various kinds of dependencies mean right |
22 |
-- as you saw in the "what's available in pkg_setup?" discussion, we |
23 |
have to be very very careful to avoid contradictions. |
24 |
|
25 |
I think we need at least the following classes to represent all the |
26 |
different dependencies people seem to need: |
27 |
|
28 |
Build dependencies (DEPEND): available in src_*. |
29 |
|
30 |
Run dependencies (RDEPEND): available when the package is used to |
31 |
satisfy a dependency. |
32 |
|
33 |
Install dependencies (IDEPEND?): available in pkg_setup. (Anyone |
34 |
interested in why this is necessary should see the "Rephrasing *DEPEND" |
35 |
thread on gentoo-pms. Sticking something in both DEPEND and RDEPEND |
36 |
isn't enough, since RDEPEND-RDEPEND cycles are breakable. But please |
37 |
read the original discussion before claiming we're wrong.) |
38 |
|
39 |
Build-against dependencies (BDEPEND?): the thing described in the |
40 |
original post in this thread. |
41 |
|
42 |
Post dependencies (PDEPEND): available sometime. |
43 |
|
44 |
Suggested dependencies (SDEPEND?): optionally available sometime. |
45 |
|
46 |
We may also want: |
47 |
|
48 |
Recommended dependencies (TDEPEND?): optionally available sometime, |
49 |
and chosen unless the user says not to. |
50 |
|
51 |
If we're trying to solve the SCM fetch problem in EAPI 5 (I don't think |
52 |
we are): |
53 |
|
54 |
Special Fetch dependencies (FDEPEND?): available during the special |
55 |
fetch phase, however we decide to do that. |
56 |
|
57 |
Note that suggested dependencies *have* to be PDEPEND-like. You can't |
58 |
sensibly have suggested DEPENDs, since that violates the "repeatable |
59 |
builds" principle. If something's an optional DEPEND, it needs a flag. |
60 |
|
61 |
-- |
62 |
Ciaran McCreesh |