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 CEF181381F3 for ; Sun, 16 Jun 2013 14:37:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A512DE0957; Sun, 16 Jun 2013 14:37:51 +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 A77C4E094F for ; Sun, 16 Jun 2013 14:37:50 +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 8BEF733E0CB for ; Sun, 16 Jun 2013 14:37:49 +0000 (UTC) Message-ID: <51BDCE1C.5000505@gentoo.org> Date: Sun, 16 Jun 2013 10:39:24 -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> <20130615150549.5faa3829@gentoo.org> <51BD05A6.4090209@gentoo.org> In-Reply-To: <51BD05A6.4090209@gentoo.org> X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 27b3fd57-7944-4ea4-bdf6-41b58fd3d66d X-Archives-Hash: 63d9b1d5819d1d6965707c09be119f9a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2013 08:24 PM, Zac Medico wrote: > On 06/15/2013 06:05 AM, Michał Górny wrote: >> Dnia 2013-06-15, o godz. 15:56:53 >> "Vadim A. Misbakh-Soloviov" napisał(a): >> >>> 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 >>> " >> >> It simply can't work. Don't even try to implement, it's waste of time. >> Just grep the tree, see how various packages use VCS-es. There's too >> many differences, too many needs and -- most importantly -- VCS-es >> change over time much more quickly than, say, unpackers. >> >> Even *if* we get a SRC_URI VCS support that works for all consumers, >> and that'd be awfully hard to do properly, it will eventually stop >> being 'good enough' and require further changes. It will just become >> never-ending story for a minor benefit. > > How about it we add a src_fetch phase, so that the VCS intricacies can > be delegated to ebuilds/eclasses (like they are now, but without having > to abuse src_unpack). If we include a way for src_fetch to communicate > changes in VCS revisions to the package manager, then we'll be able to > integrate functionality like smart-live-rebuild directly into the > package manager (as discussed in bug 182028 [1]). > > [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 +1 on src_fetch in or out of the context of this thread. +1 on more granular fetch/mirror restrictions +-0 on VCS in SRC_URI, as I already stated I'm fine with the current functionality (aside from a vast desire for src_fetch phase). - -Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG 6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1 NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n 1PD6mk8hNr9C3aV14QzM =7DTn -----END PGP SIGNATURE-----