From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E12CF1381F3 for ; Sat, 15 Jun 2013 13:34:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC6E8E09DA; Sat, 15 Jun 2013 13:34:32 +0000 (UTC) Received: from a1www.kph.uni-mainz.de (a1www.kph.uni-mainz.de [134.93.134.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D2E90E09C2 for ; Sat, 15 Jun 2013 13:34:31 +0000 (UTC) Received: from a1i15.kph.uni-mainz.de (a1i15.kph.uni-mainz.de [134.93.134.92]) by a1www.kph.uni-mainz.de (8.14.4/8.13.4) with ESMTP id r5FDYSGh031626 for ; Sat, 15 Jun 2013 15:34:28 +0200 Received: from a1i15.kph.uni-mainz.de (localhost [127.0.0.1]) by a1i15.kph.uni-mainz.de (8.14.6/8.14.2) with ESMTP id r5FDYSnv032569; Sat, 15 Jun 2013 15:34:28 +0200 Received: (from ulm@localhost) by a1i15.kph.uni-mainz.de (8.14.6/8.14.6/Submit) id r5FDYRCQ032567; Sat, 15 Jun 2013 15:34:27 +0200 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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20924.28003.927022.484836@a1i15.kph.uni-mainz.de> Date: Sat, 15 Jun 2013 15:34:27 +0200 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] SRC_URI behaviour In-Reply-To: References: <51BC2C55.7010506@mva.name> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) From: Ulrich Mueller X-Archives-Salt: 6dd4d735-17f9-4e8b-bb9b-0a1fb90966cf X-Archives-Hash: 73d6f2cc3c0a65e4dbc5d8148c9ada81 >>>>> On Sat, 15 Jun 2013, Rich Freeman wrote: >> Over my dead CVS access. > Grandstanding aside, it is probably best to take this in chunks. > The all-or-nothing fetch restriction control does seem like a good > place to start improving. I could certainly see where that could > create needless problems. It just hasn't been much of an issue > because fetch restriction is rare. Mirror restriction is likely a > bigger problem even if it is somewhat user-invisible. Do we really > want to hammer something like dev.gentoo.org for patches that aren't > properly mirrored because the original source cannot be? Trying to get this thread back on track: This part was already proposed in bug 371413. I guess the main problem is to come up with a good syntax for SRC_URI or RESTRICT. "restrict+http:" (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. Ulrich