On Sat, 13 Aug 2011 12:10:45 +0200
Ulrich Mueller <email@example.com> wrote:
> >> Except that large parts of the tree rely on packages in RDEPEND
> >> being available in pkg_*.
> > Then those packages are broken.
> Welcome to reality. ;-)
Reality is that RDEPEND cycle breaking happens, so those packages only
work if by fluke they're not in an RDEPEND cycle.
Now, we *could* weasel our way out of it by saying that it's illegal
for any repository to include a package that would induce such a cycle
between packages that rely upon the intersection of DEPEND and RDEPEND
being available in pkg_*. But that's pretty horrible, so if we do that
then we really need to fix things in future EAPIs.
> I'm not convinced. IDEPEND would cover a very specific usage case, and
> IMHO it wouldn't be so different from an intersection of DEPEND and
The thing is, RDEPEND-RDEPEND cycles *have* to be breakable. There are
enough genuine instances in the tree that we can't simply turn RDEPEND
into "DEPEND for binaries".
> Not different enough to justify introduction of another variable.
Well... You say loads of packages in the tree rely upon it... So I'd
say it's rather a common use case. And making it explicit makes things
easy for developers, since it's fairly apparent that the subtleties of
the different *DEPENDs are lost on most people. "If you use it in pkg_*
it belongs in IDEPEND" is easy.
> Maybe package managers could introduce it as an internal variable
> (containing packages common to DEPEND and RDEPEND)?
That's a little fiddly and ill-specified... If DEPEND has cat/pkg and
RDEPEND has >=cat/pkg-1.23, are they common? What about foo? ( cat/pkg
) vs an unconditional cat/pkg?
> And in case that we should at some point switch to an Exherbo-style
> syntax for dependencies, then it could be specified explicitly?
I'm pretty much operating on the assumption that we'll have at least
SDEPEND in the next EAPI, and the embedded people have been after
compiled-against-DEPEND for five years or more, so I suspect we a
single var syntax of some kind or other... Whether it's just labels,
just annotations, mixed labels and annotations Exherbo-style or
something else, I don't know...