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

["Michał Górny" <mgorny@gentoo.org>]

Dnia December 16, 2019 1:16:12 PM UTC, Ulrich Mueller <ulm@gentoo.org> napisał(a):
>>>>>> 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.

Actually, what about the original example provided by Vadim? It's a game + translations, all rights reserved. We can't mirror them but we can fetch them.

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


--
Best regards, 
Michał Górny