-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/04/2012 01:02 PM, Michael Mol 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.)
>
> 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.)
>
All the live eclasses already drop a checkout (or whatever term you
like) of the repo in /usr/portage/distfiles. What we are talking about
here is separating the "download/checkout into /usr/portage/distfiles"
from the "copy from /usr/portage/distfiles to ${S}". Making this two
separate phases would allow a reasonably sane "emerge -f blah" support
to fetch the live sources before build.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQRjk9AAoJEKXdFCfdEflKeocQAJgSMaycMkvmdalYWUBU4lRJ
eNilSxWoMAuln+1FMRv9HxavQCMzkw/h9o3Lwy75Kv2+Z/MZy60caG7yplexSKEf
Z3apTwU1Cbj7WasDNkNRXgoHHsn55Fnr28lueFmcAlvMWDnBV0TmXCYFiRh961hN
7Co3wbHT4ahk1TTTURFDoWbE2R24e1UJFzrWRRO4oyoIDqPqOIOqhR+4Nnl5vsXa
/UQmvIqgzxlWgdjeaWceQxgexPt0g+ZwFUFIF6FhL3xqoF6kokBj64VxPRAgK05X
x78LSsul+A0H6sAU4S9e5CmZekxFyNanF3PJ5aZaAfp8dPTWaUFIhJHh3jDFktdT
zaO1LVpEOVnUenuV6XgpETN8XxThZHzXFRokuyR3Aza41/p3eg/jo07DGmUBLRP2
fu9h/ZVwrcPixgpTNd2+8YhxIxuoka7CmJiVb4ncAJ/Yp95G64dM57DXf46rKPTC
6LX/5jQgXcR+WbQswLumZJ+EJ7aIzGhJRFGXZmbNvWVrzFxfB7vtgUl6NUsKmzTo
gffrxrZexzlnvkCThrdM1C89BdAdkWATICiAAEkf2P9gzEdtB+p65VBqYcNzFc+Q
X9kw+X6lnAn6D/KqJdSAG9plhjRuZ9JTGnZ/ZlucyP7uVnmHV5+NOVn5MYvZ/Sso
z2F4QPIJi3C9LQkOSyKF
=vy05
-----END PGP SIGNATURE-----
