Summary: | allow flexible mirror settings based per repository | ||
---|---|---|---|
Product: | Portage Development | Reporter: | cJ <cJ-gentoo> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | esigra, Ikonta, jakub, jstein, radek |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240187 |
Description
cJ
2008-01-13 21:30:27 UTC
Well, after eating more sushi I figured that the main problem was that portage is doing stuff that isn't specified in the ebuilds. The ebuild can tell SRC_URI="original_uri mirror://sourceforge/package mirror://gentoo/package". IMHO a good guideline would be to well document SRC_URI and don't modify portage ;) (In reply to comment #1) > Well, after eating more sushi I figured that the main problem was that portage > is doing stuff that isn't specified in the ebuilds. > > The ebuild can tell SRC_URI="original_uri mirror://sourceforge/package > mirror://gentoo/package". That completely defeats the whole purpose of mirroring. Gentoo mirrors are used whenever there's not RESTRICT="mirror" in the ebuild. Absolutely no point in bloating ebuilds' SRC_URI. If you don't want portage to try to fetch stuff from mirrors in your custom ebuilds, the either use RESTRICT, or pass GENTOO_MIRRORS="" to emerge on command-line. Your suggestion works (but GENTOO_MIRRORS="" emerge stuff can't be automated). I suggest documenting RESTRICT="mirror" for ebuild developers who know that (atm) their package isn't in the gentoo mirrors. Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if repo_name != gentoo (In reply to comment #4) > Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if > repo_name != gentoo That sucks for local overlays that only contain modified versions of in-tree ebuilds. Best bet seems to be in comment #0 "Maybe (as jokey suggested) there should be a config file telling which repositories (overlays) have files on gentoo mirrors." (as we're going to need such a repo config file anyway for other reasons) (In reply to comment #0) > I was told my proposition is bad, since it means more work to do when pushing > the ebuild in the gentoo repository. I don't buy into this excuse. It's not hard to strip RESTRICT="primaryuri" from an ebuild. This piece of metadata is useful and if it doesn't fit your use case then I'd suggest that we create a new piece of ebuild-level metadata to suit your needs. Now we probably can easely fix this bug. See https://bugs.gentoo.org/show_bug.cgi?id=367479#c8 (In reply to Marius Mauch (RETIRED) from comment #5) > (In reply to comment #4) > > Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if > > repo_name != gentoo > > That sucks for local overlays that only contain modified versions of in-tree > ebuilds. Why? To my mind user may want to modify existing ebuild after unstatisfied (install, i.e. fetch distfiles) its primary version. So it doesn't matter at all. More complex is a question about particular reuse of mirror space. But it as a question not to portage, but to mirroring logic and structure. "Previous policy was to use mirror://gentoo directly, but this is now deprecated, as that wouldn't allow to have long-term availability and traceability of the source files, which might be a requirement of the license. " https://devmanual.gentoo.org/general-concepts/mirrors/ SRC_URI should never contain mirror://gentoo anymore. |