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 2EBC51381F3 for ; Sat, 15 Jun 2013 15:12:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98EC7E09FF; Sat, 15 Jun 2013 15:11:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B7A93E09FB for ; Sat, 15 Jun 2013 15:11:28 +0000 (UTC) Received: from [192.168.1.9] (pool-71-245-176-92.pitbpa.fios.verizon.net [71.245.176.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id C83C033DFE1 for ; Sat, 15 Jun 2013 15:11:27 +0000 (UTC) Message-ID: <51BC847A.6050109@gentoo.org> Date: Sat, 15 Jun 2013 11:12:58 -0400 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130524 Thunderbird/17.0.6 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] SRC_URI behaviour References: <51BC2C55.7010506@mva.name> In-Reply-To: <51BC2C55.7010506@mva.name> X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 5b317350-43a1-485a-8b06-fbd193150b2f X-Archives-Hash: 4579bb218beee13200df93ac62f6e3f6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2013 04:56 AM, Vadim A. Misbakh-Soloviov wrote: > Sometimes I find myself in a situation, when I need to use both > RESTRICT=fetch for the main distfile and allow fetch for additional ones > (langpacks, extensions and so on). > Sometimes it is even impossible to split that additions into separate > package, since they might want to replace some file (for example, Dear > Esther's translations). > > So, in that case, I think, it'd be useful to change SRC_URI behaviour a > bit: > > for example: > > SRC_URI=" > restrict://dearesther-linux-06082013-bin #fetch restrict > linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar ) > linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) > linguas_hu2? ( > http://www.dear-esther.com/translations/DE_Hungarian2.rar ) > " > Alternatively it can be even: > > SRC_URI=" > restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a > link for fetch-restrict (like for oracle-jdk) > " I think something like this would be extremely valuable. Sometimes one file is fetch restricted and the rest are not and we currently don't handle that at all. If you want to write an implementation for it, I think it's great. > > And, moreover, I guess, SRC_URI can even be used for VCS: > > SRC_URI=" > git+ssh://github.com/lol/moo.git > hg+ssh://bitbucket.org/lol/moo > svn+ssh://assembla.com/lol/moo > " > > And it can also be extendable: > > SRC_URI=" > hg+http://prosody.im/trunk > modules? ( hg+https://prosody-modules.googlecode.com/hg ) > " I don't quite agree with "Over my dead CVS access" but yeah, this isn't really a great idea or needed. The current way to fetch live things is both functional and simple enough to be in very wide use. There is currently no need for improvement in my eyes, and I'm not sure this could be considered improvement anyway. Thanks, Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvIR6AAoJEKXdFCfdEflKns8QAJq4N0VDwoLTda5ptmEXhrH9 O6CBNAvz+f4cG/lA9bKRxqjWfce44KQbSCO/nieabLLNTNEtNn+xbdz5AHGJxEKa muxJNhHiUNjqN6J9IyXNqlpV1hC0mrxroN9hTL7HnryJKzLXx7t+IIpnjyFZDdho bw9PH1boAt7YN4FRctoV3ALAXU3zY+v/rJNAoDAwfajteZRipRPEnfGEVeuKjm7o 8PY39eBGmgKzQLoz67RTVVgNwOnsyHeJWJX8XWXaURK/2Lh/jBOdSP23xgh50K20 e4zDdRYHP6YH0vFraIjo9d17NtuuzI3SW78BL8JMHdNbQl7XY5khN/Z/KuKy3ydH ccQba25Snkuz0tL+DBnpMb5JkLz02Jup2ug6VqTPwCTtCykRvDF9jf0JLEcNfEd2 8Tkqn4Jah5+zqYox0xIxlJmwLvnlH8Jc7OLuZEIEjt4x3tEXf8mDSSpWV90aI+A2 7dHi9ealEPAPTdt7LqHuJ6ic7akPH4o/lTE+Yp/OcSIUrAfWThxiLUkgD3vbBh/E ZzQFuIqrtptXWP8jGhw01bcqRp6MfOSuCe5G6pEdR0N8Ud5qnyZyPWeMf/1hUxMy g4RMge28KDscnQy+Z0D0BNGSyYuru5mP+vLnfqKHnUjNzxSSbIXj3F98nXykhVvQ SyGs/KBmBdtLVGqrqVWl =gBw2 -----END PGP SIGNATURE-----