Summary: | emerge fetch function should be mirror-selective depending on ebuild location | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 377365 |
Description
Sergey S. Starikoff
2011-05-16 07:15:19 UTC
This seem like a possible duplicate of either bug 205709 or bug 299181 (see comments about RESTRICT=primaryuri). (In reply to comment #1) > This seem like a possible duplicate of either bug 205709 or bug 299181 (see > comments about RESTRICT=primaryuri). Yes, the issue is exactly like described in bug 205709 only suggested solution differs. Asking primary URLs/mirrors first I think is incorrect. Putting RESTRICT="mirror" into ebuilds in non-maintree overlays (+ update documentation and ebuilds update maintainer-addresed request) and updating repoman adding check of distfiles on GENTOO_MIRRORS if restriction is not present in ebuilds in additional overlays seems to be better solution. (In reply to comment #2) > Putting RESTRICT="mirror" into ebuilds in non-maintree overlays (+ update > documentation and ebuilds update maintainer-addresed request) I think using RESTRICT="mirror" for this is going to be confusing, since the common meaning of this setting is that the file(s) should not be mirrored due to license requirements. If RESTRICT="primaryuri" is also unsuitable for some reason, then I'd suggest the we invent some new metadata for the specific use case that we are considering. (In reply to comment #3) > (In reply to comment #2) > > Putting RESTRICT="mirror" into ebuilds in non-maintree overlays (+ update > > documentation and ebuilds update maintainer-addresed request) > > I think using RESTRICT="mirror" for this is going to be confusing, since the > common meaning of this setting is that the file(s) should not be mirrored due > to license requirements. If RESTRICT="primaryuri" is also unsuitable for some > reason, then I'd suggest the we invent some new metadata for the specific use > case that we are considering. RESTRICH="primaryurl" looks for me too high-weight. There may be another solution: search deistfiles on GENTOO_MIRRORS only for not-restricted ebuilds in main tree. If it is possible depending on package metadata identify custom (overlay) builds of main tree packages (which distfiles could and should be fetched from GENTOO_MIRRORS)... Otherwise I think that functionally RESTRICT="mirror" solves issue. For escaping confusing may be ebough to create an alias (restriction with the same functionality) for "mirror", named, for example "overlay". Which should be used to prevent packages in overlays to search missed on official mirrors distfiles. With adding this restriction in ebuild skels in all editors and describing issue in documentation. Find in unofficial wiki key: RESTRICT="NOMIRROR" seems to be a solution. (In reply to comment #5) > Find in unofficial wiki key: > RESTRICT="NOMIRROR" > seems to be a solution. RESTRICT="mirror"/nomirror has a subtly different meaning (it means that it's not legal to mirror the files). Typically, RESTRICT="primaryuri" is really what you want. It means that emerge shouldn't try to fetch the file from mirrors. (In reply to comment #6) > Typically, RESTRICT="primaryuri" is really what you want. Thank you! It is. But I can solve this issue only in my local overlay. For complete solution of this issue string RESTRICT="primaryuri" is to be added into skel.ebuild (opened by vim while creating ebuild file) and added to ebuilds in overlays, which uses not distributed on official mirrors distfiles. For now (=sys-apps/portage-2.2.20) this bug has a solution. It's enough to move GENTOO_MIRRORS parametr into /etc/portage/repos.conf/${REPONAME}.conf after sync-uri. And the task could be forwarder on overlay maintainer's level. Also it should provide permitting mirror requests for overlays, which have no mirror infrastructure, most typical example — the local overlay. (In reply to Sergey S. Starikoff from comment #8) > For now (=sys-apps/portage-2.2.20) this bug has a solution. > It's enough to move GENTOO_MIRRORS parametr into > /etc/portage/repos.conf/${REPONAME}.conf after sync-uri. > And the task could be forwarder on overlay maintainer's level. > > Also it should provide permitting mirror requests for overlays, which have > no mirror infrastructure, most typical example — the local overlay. No, your wrong. 2.2.20 has a fixed repos.conf usage, it does not allow to move a global setting into a repo specific one. There is code in git now (since 2.2.20) that will allow repos specific settings for the sync modules. But that does not include settings like you are wanting. The config validation system still needs some updating/re-writing to enhance it's capabilities. But that is not a high priority item at this time. There are other tasks in greater need of completion. (In reply to Brian Dolbec from comment #9) > (In reply to Sergey S. Starikoff from comment #8) > > For now (=sys-apps/portage-2.2.20) this bug has a solution. > > It's enough to move GENTOO_MIRRORS parametr into > > /etc/portage/repos.conf/${REPONAME}.conf after sync-uri. > > And the task could be forwarder on overlay maintainer's level. > > > > Also it should provide permitting mirror requests for overlays, which have > > no mirror infrastructure, most typical example — the local overlay. > > No, your wrong. 2.2.20 has a fixed repos.conf usage, it does not allow to > move a global setting into a repo specific one. > > There is code in git now (since 2.2.20) that will allow repos specific > settings for the sync modules. But that does not include settings like you > are wanting. No. I'm right. I just wasn't clear enough. I've don't made any non-standard config changes, I just suggest to move mirror settings from top-level make.conf to per-repository config in some future release (>sys-apps/portage-2.2.20). > The config validation system still needs some updating/re-writing to enhance > it's capabilities. But that is not a high priority item at this time. > There are other tasks in greater need of completion. I agree with importance of config validation system, but it is another question. Maybe it will be reasonable to provide special interface for this function (an utility in app-portage/gentoolkit or sys-apps/portage itself). |