Repository dependencies could be supported in DEPEND, PDEPEND and RDEPEND and atoms passed to best_version() and has_version() functions.
There's no legitimate use case for this in repositories. If you need to query based upon functionality, use [use(-)] dependencies.
(In reply to comment #1)
> If you need to query based upon functionality, use [use(-)] dependencies.
Differences in behavior between ebuilds of given package in different repositories do not need to be reflected in differences in IUSE.
Well they certainly aren't reflected in ::repository dependencies. Querying based upon what repository something is in is asking the wrong question.
Also, unless you're changing the meaning of ::repository from what it is, ::repository dependencies do not match both repo packages and installed packages. When a package is installed, it is in ::installed, and is no longer in ::repo.
(In reply to comment #3)
::repository dependencies match installed packages in case of Portage.
That's a change from original behaviour, but it still doesn't address the root problem: matching against which repository something is in is always the wrong question to ask.
Did someone mentioned already that it's misleading to users? Portage users were always able to copy a package to local overlay and patch it. With repo dependencies, you will prohibit them from doing it (and they will be surprised it doesn't work as expected).
I agree. Ebuilds should behave identical, regardless of the repository they are located in.
*** Bug 544094 has been marked as a duplicate of this bug. ***
Though repository dependencies are annoying for public repositories, they can be quite useful for users of private repositories. For example, a public ebuild might need to be forked into a private repository for some reason, and maybe it makes sense to have private ebuilds pull specify that they need the forked ebuild from a particular private repository.
Closing per comment #1, comment #6, and comment #7.