Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 414815 - [Future EAPI] Support for repository dependencies in DEPEND, PDEPEND and RDEPEND and atoms passed to best_version() and has_version() functions
Summary: [Future EAPI] Support for repository dependencies in DEPEND, PDEPEND and RDEP...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
: 544094 (view as bug list)
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2012-05-06 02:56 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2018-03-23 07:41 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis 2012-05-06 02:56:03 UTC
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]
Comment 1 Ciaran McCreesh 2012-05-06 14:16:57 UTC
There's no legitimate use case for this in repositories. If you need to query based upon functionality, use [use(-)] dependencies.
Comment 2 Arfrever Frehtes Taifersar Arahesis 2012-05-06 14:25:18 UTC
(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.
Comment 3 Ciaran McCreesh 2012-05-06 14:29:31 UTC
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.
Comment 4 Arfrever Frehtes Taifersar Arahesis 2012-05-06 14:41:20 UTC
(In reply to comment #3)

::repository dependencies match installed packages in case of Portage.
Comment 5 Ciaran McCreesh 2012-05-06 14:47:06 UTC
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.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-08-14 07:26:11 UTC
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).
Comment 7 Ulrich Müller gentoo-dev 2012-08-14 07:38:23 UTC
I agree. Ebuilds should behave identical, regardless of the repository they are located in.
Comment 8 Arfrever Frehtes Taifersar Arahesis 2012-09-11 17:47:51 UTC
Portage commit:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=caf67ac8df3528382ff960b2de4cf853a14a0141
Comment 9 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-03-28 18:21:02 UTC
*** Bug 544094 has been marked as a duplicate of this bug. ***
Comment 10 Zac Medico gentoo-dev 2015-04-16 20:28:21 UTC
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.
Comment 11 Ulrich Müller gentoo-dev 2018-03-23 07:41:20 UTC
Closing per comment #1, comment #6, and comment #7.