From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3A94E138334 for ; Fri, 20 Dec 2019 09:20:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6821E0880; Fri, 20 Dec 2019 09:20:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 96142E0878 for ; Fri, 20 Dec 2019 09:20:24 +0000 (UTC) Received: from [10.155.7.247] (apn-31-0-46-31.dynamic.gprs.plus.pl [31.0.46.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id C6CFA34D7C6; Fri, 20 Dec 2019 09:20:22 +0000 (UTC) Date: Fri, 20 Dec 2019 09:20:14 +0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <293656848f42786552da59ad307058d597efa026.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction To: gentoo-dev@lists.gentoo.org,Ulrich Mueller CC: gentoo-dev From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= Message-ID: <1E1A184D-EC5F-43FF-B4EF-C6B4AE9EC332@gentoo.org> X-Archives-Salt: fbe19963-ca38-4371-801e-8e5828a28714 X-Archives-Hash: 04856b7c23d893563c3af12f0ad27fc0 Dnia December 16, 2019 1:16:12 PM UTC, Ulrich Mueller na= pisa=C5=82(a): >>>>>> On Mon, 16 Dec 2019, Micha=C5=82 G=C3=B3rny wrote: > >> Proposed solution >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The current proposal is based on extending the current URI syntax to >> permit excluding individual files from the restriction=2E The idea is >to >> prepend 'fetch+' to protocol to undo fetch restriction, or to prepend >> 'mirror+' to undo fetch & mirror restrictions=2E > >> Example 1: removing mirror restriction from files > >> RESTRICT=3D"mirror" >> SRC_URI=3D"https://example=2Ecom/you-cant-mirror-this=2Etar=2Ebz2 >> mirror+https://example=2Ecom/but-you-can-mirror-this=2Etar=2Egz" > >> Example 2: removing fetch & mirror restriction from files > >> RESTRICT=3D"fetch" >> SRC_URI=3D"https://example=2Ecom/you-cant-fetch-this=2Ezip >> mirror+https://example=2Ecom/but-you-can-mirror-this=2Etar=2Egz" > >> Example 3: removing fetch restriction while leaving mirror >restriction > >> RESTRICT=3D"fetch" >> SRC_URI=3D"https://example=2Ecom/you-cant-fetch-this=2Ezip >> fetch+https://example=2Ecom/you-cant-mirror-this=2Etar=2Ebz2" > >Looks good, but what is slightly confusing is that it doesn't map >one-to-one to the RESTRICT tokens: > >- RESTRICT=3D"mirror" enables mirror restriction, and it is undone by > "mirror+", as expected=2E > >- RESTRICT=3D"fetch" enables both fetch and mirror restriction, but it is > undone by "mirror+" as well, not by "fetch+" (which disables only > fetch restriction)=2E > >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=2E Actually, what about the original example provided by Vadim? It's a game += translations, all rights reserved=2E We can't mirror them but we can fetch= them=2E > >Ulrich > >> [1] https://bugs=2Egentoo=2Eorg/371413 -- Best regards,=20 Micha=C5=82 G=C3=B3rny