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

[Michael Mol]

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.)

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.)

Other common remote mounts (such as cifs) may have restrictions that
could force munging of filenames, too, and VCS infrastructures (or
even unpacked checkouts with strange filenames) placed on those
filesystems may have unanticipated results.

It may be helpful to have some kind of adapter mount in place, or even
generate a tarball of the local copy and store that instead. (That'd
be problematic if multiple boxes were modifying the local copy on the
same share, but that's obviously problematic anyway.)

-- 
:wq