On Tue, Sep 11, 2012 at 06:36:46PM -0400, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/06/2012 02:50 PM, Micha?? G??rny wrote:
> > On Thu, 6 Sep 2012 09:49:13 -0700
> > Brian Harring <ferri...@gmail.com> wrote:
> >
> >> 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.
>
> Realizing this is a late response I would like to add.... Um, what?
> src_fetch should only be putting things into /usr/portage/distfiles,
> never into ${WORKDIR}, that's for src_unpack to handle.
>
> Am I missing something here?
WORKDIR was an example; punting it directly into the pkgs distfiles is
also fine.
Basically, you're assuming that the content *is* cachable- cause if it
isn't, then dumping in ${DISTDIR} is wasteful (both since it'll
require a copy into the ebuild's workdir, and since it means
increasing crap accumulating in the workdir).
Further, there are cases where content *is* available, but is
fundamentally outside ${DISTDIR}- in cros, they have the
chrome/chromium source available in certain cases.
Now, either we can store 13GB int ${DISTDIR} that's a copy of that
external developer checkout, then copy that into ${WORKDIR}, or w/ a
restrict marker, copy that sucker into ${WORKDIR} directly.
Is it a corner case? Yep, but it's easy enough to deal w/- the only
constraint there is that the src_fetch's target dir isn't ${DISTDIR},
it's ${WORKDIR}, and the PM is required to preserve ${WORKDIR} from
src_fetch to the time of that pkg actually running.
~harring
