1 |
On Sat, 13 Aug 2011 12:10:45 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> >> Except that large parts of the tree rely on packages in RDEPEND |
4 |
> >> being available in pkg_*. |
5 |
> |
6 |
> > Then those packages are broken. |
7 |
> |
8 |
> Welcome to reality. ;-) |
9 |
|
10 |
Reality is that RDEPEND cycle breaking happens, so those packages only |
11 |
work if by fluke they're not in an RDEPEND cycle. |
12 |
|
13 |
Now, we *could* weasel our way out of it by saying that it's illegal |
14 |
for any repository to include a package that would induce such a cycle |
15 |
between packages that rely upon the intersection of DEPEND and RDEPEND |
16 |
being available in pkg_*. But that's pretty horrible, so if we do that |
17 |
then we really need to fix things in future EAPIs. |
18 |
|
19 |
> I'm not convinced. IDEPEND would cover a very specific usage case, and |
20 |
> IMHO it wouldn't be so different from an intersection of DEPEND and |
21 |
> RDEPEND. |
22 |
|
23 |
The thing is, RDEPEND-RDEPEND cycles *have* to be breakable. There are |
24 |
enough genuine instances in the tree that we can't simply turn RDEPEND |
25 |
into "DEPEND for binaries". |
26 |
|
27 |
> Not different enough to justify introduction of another variable. |
28 |
|
29 |
Well... You say loads of packages in the tree rely upon it... So I'd |
30 |
say it's rather a common use case. And making it explicit makes things |
31 |
easy for developers, since it's fairly apparent that the subtleties of |
32 |
the different *DEPENDs are lost on most people. "If you use it in pkg_* |
33 |
it belongs in IDEPEND" is easy. |
34 |
|
35 |
> Maybe package managers could introduce it as an internal variable |
36 |
> (containing packages common to DEPEND and RDEPEND)? |
37 |
|
38 |
That's a little fiddly and ill-specified... If DEPEND has cat/pkg and |
39 |
RDEPEND has >=cat/pkg-1.23, are they common? What about foo? ( cat/pkg |
40 |
) vs an unconditional cat/pkg? |
41 |
|
42 |
> And in case that we should at some point switch to an Exherbo-style |
43 |
> syntax for dependencies, then it could be specified explicitly? |
44 |
|
45 |
I'm pretty much operating on the assumption that we'll have at least |
46 |
SDEPEND in the next EAPI, and the embedded people have been after |
47 |
compiled-against-DEPEND for five years or more, so I suspect we a |
48 |
single var syntax of some kind or other... Whether it's just labels, |
49 |
just annotations, mixed labels and annotations Exherbo-style or |
50 |
something else, I don't know... |
51 |
|
52 |
-- |
53 |
Ciaran McCreesh |