| Summary: | [Future EAPI] Allow selective fetch restriction | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Justin Lecher (RETIRED) <jlec> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi, esigra, kripton, mgorny, nikoli, pacho |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=695814 | ||
| Whiteboard: | in-eapi-8 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
|
Description
Justin Lecher (RETIRED)
2011-06-13 12:15:35 UTC
It's worth noting that portage already supports this for files that have mirror:// in SRC_URI. Aside from that, we'll need an EAPI bump in order to add syntax extensions to SRC_URI. Could you point us to an example ebuild which would use this? sci-chemistry/vmd I placed the files on our miror, but if I want to put them on my devspace it fails. Given that we don't have Exherbo annotations in SRC_URI, what syntax would we use for this? (In reply to Michał Górny from comment #4) > Given that we don't have Exherbo annotations in SRC_URI, what syntax would > we use for this? A possible syntax was suggested in this thread: https://archives.gentoo.org/gentoo-dev/message/b0823618d5d3cc61bbed1e88dc2f144d Especially: https://archives.gentoo.org/gentoo-dev/message/57393f180e7c0236d635860cfa6af2e7 In a nutshell: - mirror+http: (or mirror+ftp: etc.) ignore mirror restriction for this file, - fetch+http: ignore fetch restriction for this file. (Is there an actual use case for the second one, though? I cannot come up with an example where we would want to lift fetch restriction for a specific tarball, but keep mirror restriction for it.) (In reply to Ulrich Müller from comment #5) > In a nutshell: > - mirror+http: (or mirror+ftp: etc.) ignore mirror restriction for this file, > - fetch+http: ignore fetch restriction for this file. > > (Is there an actual use case for the second one, though? I cannot come up > with an example where we would want to lift fetch restriction for a specific > tarball, but keep mirror restriction for it.) Wouldn't that be a case if an ebuild used three components, one free, one proprietary disallowing mirroring, and third that needed to be fetched manually? ;-) (In reply to Michał Górny from comment #6) > > - mirror+http: (or mirror+ftp: etc.) ignore mirror restriction for this file, Actually, mirror+ would imply that both fetch and mirror restrictions are ignored. > > - fetch+http: ignore fetch restriction for this file. > > > > (Is there an actual use case for the second one, though? I cannot come up > > with an example where we would want to lift fetch restriction for a specific > > tarball, but keep mirror restriction for it.) > > Wouldn't that be a case if an ebuild used three components, one free, one > proprietary disallowing mirroring, and third that needed to be fetched > manually? ;-) The two typical scenarios are RESTRICT="mirror" plus some free files (appearing as "mirror+..." in SRC_URI), or RESTRICT="fetch" plus free files (again, "mirror+..." in SRC_URI). I think there aren't many use cases (if any) for RESTRICT="fetch" plus some files that are mirror (but not fetch) restricted. OTOH, having both fetch+ and mirror+ will just make things error prone. (In reply to Ulrich Müller from comment #7) > The two typical scenarios are RESTRICT="mirror" plus some free files > (appearing as "mirror+..." in SRC_URI), or RESTRICT="fetch" plus free files > (again, "mirror+..." in SRC_URI). > > I think there aren't many use cases (if any) for RESTRICT="fetch" plus some > files that are mirror (but not fetch) restricted. OTOH, having both fetch+ > and mirror+ will just make things error prone. Thinking about it, having both fetch+ and mirror+ is the more orthogonal solution, from a PM point of view. So let's go for it. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=2fab50edb1db47a0b12ebb7452b16ffbcde645e5 commit 2fab50edb1db47a0b12ebb7452b16ffbcde645e5 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-05-12 22:37:00 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-05-24 05:05:32 +0000 Support selective fetch/mirror restriction for EAPI 8 Bug: https://bugs.gentoo.org/371413 Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/dep/__init__.py | 8 +++++++- lib/portage/eapi.py | 8 +++++++- lib/portage/package/ebuild/fetch.py | 14 ++++++++++++-- 3 files changed, 26 insertions(+), 4 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=2efc05522c75de6dd8e28425515b0501f8559da7 commit 2efc05522c75de6dd8e28425515b0501f8559da7 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-12-22 18:23:57 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-06-05 08:55:35 +0000 EAPI 8 has selective URI restrictions Bug: https://bugs.gentoo.org/371413 Signed-off-by: Michał Górny <mgorny@gentoo.org> [Shortened "selective-uri-restrict" label to make it fit in the margin] Signed-off-by: Ulrich Müller <ulm@gentoo.org> eapi-differences.tex | 4 ++++ ebuild-vars.tex | 18 +++++++++++++----- 2 files changed, 17 insertions(+), 5 deletions(-) |
