On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <[email protected]> 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
