Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching

[Brian Harring <ferringb@gmail.com>]

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 <mgorny@gentoo.org> 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