On Tue, 4 Sep 2012 13:02:36 -0400 Michael Mol <mike...@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgo...@gentoo.org> > 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
signature.asc
Description: PGP signature
