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

[Michał Górny]

On Tue, 4 Sep 2012 13:02:36 -0400
Michael Mol <mikemol@×××××.com> wrote:

> On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgorny@g.o>
> wrote:
> > Hello,
> >
> > As Sid Hayn raised today on #gentoo-portage, it would be useful to
> > finally have portage able to fetch updates from VCS-es independently
> > of src_unpack(). This could be used, for example, on machines
> > temporarily connected to the network -- one would then fetch files
> > while connected to the network, and perform the updates later.
> >
> > There are a few ways how we could handle that but the cleanest and
> > most universal one seems to be defining a src_fetch() phase function
> > in a future EAPI.
> >
> > In the EAPIs supporting src_fetch(), that phase function would be
> > used by PM when requesting the files to be fetched. A
> > default_src_fetch() will be declared as well, providing
> > implementation-defined code fetching files like they are fetched
> > now. Older EAPIs will simply always use that default.
> >
> > The phase function would be disjoint from the normal merge process,
> > much like pkg_pretend(). In portage, it will be called as 'portage'
> > user if FEATURES=userfetch is enabled.
> >
> > VCS eclasses supporting separated fetching would define two phase
> > functions:
> > - src_fetch() which would be responsible for fetching updates,
> > - src_unpack() which would be responsible for checking out the
> > source to work directory.
>
> The 'checking out' language for src_unpack() sounds like it assumes a
> DVCS such as mercurial or git. What about cvs or svn, where fetching
> is also checking out? (This is probably a trivial thing to clear up,
> though.)

They either stay with src_unpack() or do 'cvs up' in src_fetch()
and just copy files over in src_unpack(). Anyway, that's what they do
now -- update the copy in distfiles/cvs-src and then copy it.

> Also, where would the local copy go? distfiles? It's common for
> distfiles to be stored on, e.g. an NFS mount, so you may need to be
> careful not to place repositories there which have filesystem
> semantics that are disagreeable to NFS. (The only example I know of
> off the top of my head is svn, where the documentation warns against
> using the dbd backend on top of NFS.)

The actual code will be eclass-dependent, so it will go whatever it
goes now. No magic, no exherbo. Just plain phase function.

-- 
Best regards,
Michał Górny