> On Fri, 20 Dec 2019, Michał Górny wrote:
>>> 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";
>> I had already asked this in
Dnia December 16, 2019 1:16:12 PM UTC, Ulrich Mueller
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 ide
On Mon, 2019-12-16 at 14:16 +0100, Ulrich Mueller wrote:
> > > > > > 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
On Mon, Dec 16, 2019 at 8:33 AM Ulrich Mueller wrote:
>
> > On Mon, 16 Dec 2019, Francesco Riosa wrote:
>
> > what about getting rid of RESTRICT="fetch" and manage everything
> > inside SRC_URI? Would that be technically feasible? Ideally marking
> > only the not re-distributable download and
> On Mon, 16 Dec 2019, Francesco Riosa wrote:
> what about getting rid of RESTRICT="fetch" and manage everything
> inside SRC_URI? Would that be technically feasible? Ideally marking
> only the not re-distributable download and leaving untouched the
> others
That would have the disadvantage t
> 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 pr
Il giorno lun 16 dic 2019 alle ore 13:39 Michał Górny
ha scritto:
>
>
> Comments
>
> WDYT?
>
> what about getting rid of RESTRICT="fetch" and manage everything inside
SRC_URI? Would that be technically feasible?
Ideally marking only the not re-distributable download and leaving
untouched
Hello, everyone.
I'd like to start a series of mails dedicated to features proposed for
including in EAPI 8. For a start, I'd like to discuss the topic of
selective fetch restriction [1]. It has been discussed at least in 2013
[2], and since it's finally got chance to be included, I think it's
w
