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 <[email protected]> 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
