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 96881138010 for ; Thu, 6 Sep 2012 16:52:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6995F21C09B; Thu, 6 Sep 2012 16:51:34 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 6366821C0A0 for ; Thu, 6 Sep 2012 16:49:14 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2977046pbb.40 for ; Thu, 06 Sep 2012 09:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+XprwCbmL8ZeccOljV1KrknzcOrsS5HEYcAVd/4s8qA=; b=d9cH6Qszz19sY1Px4UedmyTyZNuzwawWyVsn06lelbH8DCJ6UBqn8mTngvEkOb0Sb1 NvgDPVWagZqajsgCJHyMeJCEIKncgyJrcIy/fXPDP/lFvlZ98scclcr0x+hi4xAQ+0s9 ba4xJ3ongvNY1QahkSFEL7sMThGD+WSSxM47YYB/vynrd0bslV0cIPqZ/lM95s8UkXb4 MVEQCPmFLpICzZc7pDQmX67CmENY76OGkxF6cHx/Wwm2PDm0WlIWQA2+4CNj6awYr6FU mZZaU+GaKvudyUMyUjmIYSF2wzZr03WnEU/eIK7/dXzbGZTGDkEjGWljCLkqRBxbX6Rv qasg== Received: by 10.66.79.166 with SMTP id k6mr4109757pax.44.1346950153769; Thu, 06 Sep 2012 09:49:13 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id pj8sm1600516pbb.60.2012.09.06.09.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 09:49:12 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Thu, 06 Sep 2012 09:49:13 -0700 Date: Thu, 6 Sep 2012 09:49:13 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: Micha?? G??rny Subject: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching Message-ID: <20120906164913.GG18495@localhost> References: <20120904184345.77696965@pomiocik.lan> <20120905082554.4bfb7452@googlemail.com> <20120905103811.6e9e2e79@pomiocik.lan> <3287936.v4OyhU68xF@grenadine> <20120905114903.3b2efe78@googlemail.com> <20120905130005.61efb834@pomiocik.lan> <20120905120722.04921249@googlemail.com> 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-Disposition: inline In-Reply-To: <20120905120722.04921249@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: cc4877ad-83dc-400c-9d84-e53be8a0fb82 X-Archives-Hash: f34ec7ad8e56c01a195ccea7f6795701 On Wed, Sep 05, 2012 at 12:07:22PM +0100, Ciaran McCreesh wrote: > On Wed, 5 Sep 2012 13:00:05 +0200 > Micha?? G??rny wrote: > > > I guess that's a pretty comprehensive "we need to do this properly" > > > then. > > > > Did I say we don't need to? We have the two eclasses which need to do > > this properly, right? So what's your problem? > > The problem is that we need to work out how to deal with this at least > for Subversion, and probably for CVS too... As much as we'd like to, we > can't just roll out a src_fetch without eclass changes. This doesn't > appear to be a trivial feature to provide. You're conflating the required phase/hook w/ existing bad implementations; they're separate. The bad implementations can't use the hook till they sort out their mess; straight forward enough. Worth noting, last I looked, git eclass actually didn't do this right either; basically merges the namespace of each remote/fetch source into the local namespace, no prefixing. Fixable, but the issue mostly comes about because of the fact we do *not* have a src_fetch in the first place. Either way, if the hook was in place, I expect the eclass level issues to be sorted shortly after; right now there isn't a reason to do that work (chicken/egg). Consider that my +1 for src_fetch also, although FDEPEND is needed or dependencies; I don't care which, getting a src_fetch has been on my todo for chrome-os for a while now. One additional thought- re: the scenarios where we don't fetch to an intermediate location, then transfer that contents into ${WORKDIR}, while a better name is needed, something along the lines of RESTRICT=fetches-into-workdir comes to mind. Basically that restriction would be interpretted as "$WORKDIR must be setup/preserved from invocation of src_fetch to actual building". Via that restrict, both scenarios should be addressed in full. ~harring