Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction

[Ulrich Mueller <ulm@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

>>>>> On Mon, 16 Dec 2019, Michał Górny wrote:

> Proposed solution
> =================
> The current proposal is based on extending the current URI syntax to
> permit excluding individual files from the restriction.  The idea is to
> prepend 'fetch+' to protocol to undo fetch restriction, or to prepend
> 'mirror+' to undo fetch & mirror restrictions.

> Example 1: removing mirror restriction from files

> RESTRICT="mirror"
> SRC_URI="https://example.com/you-cant-mirror-this.tar.bz2
>   mirror+https://example.com/but-you-can-mirror-this.tar.gz"

> Example 2: removing fetch & mirror restriction from files

> RESTRICT="fetch"
> SRC_URI="https://example.com/you-cant-fetch-this.zip
>   mirror+https://example.com/but-you-can-mirror-this.tar.gz"

> Example 3: removing fetch restriction while leaving mirror restriction

> RESTRICT="fetch"
> SRC_URI="https://example.com/you-cant-fetch-this.zip
>    fetch+https://example.com/you-cant-mirror-this.tar.bz2"

Looks good, but what is slightly confusing is that it doesn't map
one-to-one to the RESTRICT tokens:

- RESTRICT="mirror" enables mirror restriction, and it is undone by
  "mirror+", as expected.

- RESTRICT="fetch" enables both fetch and mirror restriction, but it is
  undone by "mirror+" as well, not by "fetch+" (which disables only
  fetch restriction).

I had already asked this in bug 371413 [1], but is there an actual usage
case for example 3? Because if there isn't, we might get away with only
supporting "mirror+", which should be less error prone.

Ulrich

> [1] https://bugs.gentoo.org/371413

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]