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 925D8138334 for ; Tue, 17 Dec 2019 15:21:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1F132E0899; Tue, 17 Dec 2019 15:21:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 BE0D8E086E for ; Tue, 17 Dec 2019 15:21:27 +0000 (UTC) Received: from pomiot (c142-245.icpnet.pl [85.221.142.245]) (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 32CD734D9D0; Tue, 17 Dec 2019 15:21:26 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 17 Dec 2019 16:21:21 +0100 In-Reply-To: References: <293656848f42786552da59ad307058d597efa026.camel@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-2hXFvSY3G9+q85l3CPZV" User-Agent: Evolution 3.32.5 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 X-Archives-Salt: 57f785c1-c432-4d11-a184-2eb5a4dc8016 X-Archives-Hash: 0bdc7c32dec2ab47ee4362e9dfd864cd --=-2hXFvSY3G9+q85l3CPZV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2019-12-16 at 14:16 +0100, Ulrich Mueller wrote: > > > > > > 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. 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=3D"mirror" > > SRC_URI=3D"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=3D"fetch" > > SRC_URI=3D"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=3D"fetch" > > SRC_URI=3D"https://example.com/you-cant-fetch-this.zip > > fetch+https://example.com/you-cant-mirror-this.tar.bz2" >=20 > Looks good, but what is slightly confusing is that it doesn't map > one-to-one to the RESTRICT tokens: >=20 > - RESTRICT=3D"mirror" enables mirror restriction, and it is undone by > "mirror+", as expected. >=20 > - 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). >=20 > 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. >=20 Does this really solve the problem? The labels are still the other way around, except that you throw 'fetch+' away as invalid. While at it, I'm wondering if 'mirror+mirror://foo' can be confusing. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-2hXFvSY3G9+q85l3CPZV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl348nJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA7uJgf+IseC6+sLOlLmPFS0FH1DD7vSq7nmnpo1aCXz7hn8U6b7f2/Z2SKOBH78 hiq84loLr7rajxdPoMaB1NtKosOnhzIr0hgtejgKhFTsMBzPd1G24n5nWVfXBTkx tPqJ3tcLQgjRtyhcDeHmIh3D+C/FH4/7iZcnqtW9UcD8wBS7Xz3knBqZ35nCz5Y0 E2yvhvV2S0MdrSRoEi/s+cSxYSKoJqSj0wI5wMaf8WyHNLlcgOxY5XAJj+d73At1 ab1e8aYxyltEvotP9gkBHy+UnN5zlWObPlhnv9sJIgjooXf1lM+VIqy1Dzu0twKj VAg8SRUtgeADTPnIzmStKuOADFsNLg== =2hup -----END PGP SIGNATURE----- --=-2hXFvSY3G9+q85l3CPZV--