| Summary: | [Future EAPI] Support for repository dependencies in DEPEND, PDEPEND and RDEPEND and atoms passed to best_version() and has_version() functions | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Arfrever Frehtes Taifersar Arahesis <arfrever.fta> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | esigra, Ikonta |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
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. Portage commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=caf67ac8df3528382ff960b2de4cf853a14a0141 *** 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. |
Repository dependencies could be supported in DEPEND, PDEPEND and RDEPEND and atoms passed to best_version() and has_version() functions. Example: =category/package-version:slot::repository[USE_flags]