| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 09/04/2012 01:02 PM, Michael Mol wrote: |
| 5 |
> On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgorny@g.o> wrote: |
| 6 |
>> Hello, |
| 7 |
>> |
| 8 |
>> As Sid Hayn raised today on #gentoo-portage, it would be useful to |
| 9 |
>> finally have portage able to fetch updates from VCS-es independently |
| 10 |
>> of src_unpack(). This could be used, for example, on machines |
| 11 |
>> temporarily connected to the network -- one would then fetch files |
| 12 |
>> while connected to the network, and perform the updates later. |
| 13 |
>> |
| 14 |
>> There are a few ways how we could handle that but the cleanest and most |
| 15 |
>> universal one seems to be defining a src_fetch() phase function |
| 16 |
>> in a future EAPI. |
| 17 |
>> |
| 18 |
>> In the EAPIs supporting src_fetch(), that phase function would be used |
| 19 |
>> by PM when requesting the files to be fetched. A default_src_fetch() |
| 20 |
>> will be declared as well, providing implementation-defined code |
| 21 |
>> fetching files like they are fetched now. Older EAPIs will simply |
| 22 |
>> always use that default. |
| 23 |
>> |
| 24 |
>> The phase function would be disjoint from the normal merge process, |
| 25 |
>> much like pkg_pretend(). In portage, it will be called as 'portage' |
| 26 |
>> user if FEATURES=userfetch is enabled. |
| 27 |
>> |
| 28 |
>> VCS eclasses supporting separated fetching would define two phase |
| 29 |
>> functions: |
| 30 |
>> - src_fetch() which would be responsible for fetching updates, |
| 31 |
>> - src_unpack() which would be responsible for checking out the source |
| 32 |
>> to work directory. |
| 33 |
> |
| 34 |
> The 'checking out' language for src_unpack() sounds like it assumes a |
| 35 |
> DVCS such as mercurial or git. What about cvs or svn, where fetching |
| 36 |
> is also checking out? (This is probably a trivial thing to clear up, |
| 37 |
> though.) |
| 38 |
> |
| 39 |
> Also, where would the local copy go? distfiles? It's common for |
| 40 |
> distfiles to be stored on, e.g. an NFS mount, so you may need to be |
| 41 |
> careful not to place repositories there which have filesystem |
| 42 |
> semantics that are disagreeable to NFS. (The only example I know of |
| 43 |
> off the top of my head is svn, where the documentation warns against |
| 44 |
> using the dbd backend on top of NFS.) |
| 45 |
> |
| 46 |
> Other common remote mounts (such as cifs) may have restrictions that |
| 47 |
> could force munging of filenames, too, and VCS infrastructures (or |
| 48 |
> even unpacked checkouts with strange filenames) placed on those |
| 49 |
> filesystems may have unanticipated results. |
| 50 |
> |
| 51 |
> It may be helpful to have some kind of adapter mount in place, or even |
| 52 |
> generate a tarball of the local copy and store that instead. (That'd |
| 53 |
> be problematic if multiple boxes were modifying the local copy on the |
| 54 |
> same share, but that's obviously problematic anyway.) |
| 55 |
> |
| 56 |
|
| 57 |
All the live eclasses already drop a checkout (or whatever term you |
| 58 |
like) of the repo in /usr/portage/distfiles. What we are talking about |
| 59 |
here is separating the "download/checkout into /usr/portage/distfiles" |
| 60 |
from the "copy from /usr/portage/distfiles to ${S}". Making this two |
| 61 |
separate phases would allow a reasonably sane "emerge -f blah" support |
| 62 |
to fetch the live sources before build. |
| 63 |
-----BEGIN PGP SIGNATURE----- |
| 64 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 65 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 66 |
|
| 67 |
iQIcBAEBAgAGBQJQRjk9AAoJEKXdFCfdEflKeocQAJgSMaycMkvmdalYWUBU4lRJ |
| 68 |
eNilSxWoMAuln+1FMRv9HxavQCMzkw/h9o3Lwy75Kv2+Z/MZy60caG7yplexSKEf |
| 69 |
Z3apTwU1Cbj7WasDNkNRXgoHHsn55Fnr28lueFmcAlvMWDnBV0TmXCYFiRh961hN |
| 70 |
7Co3wbHT4ahk1TTTURFDoWbE2R24e1UJFzrWRRO4oyoIDqPqOIOqhR+4Nnl5vsXa |
| 71 |
/UQmvIqgzxlWgdjeaWceQxgexPt0g+ZwFUFIF6FhL3xqoF6kokBj64VxPRAgK05X |
| 72 |
x78LSsul+A0H6sAU4S9e5CmZekxFyNanF3PJ5aZaAfp8dPTWaUFIhJHh3jDFktdT |
| 73 |
zaO1LVpEOVnUenuV6XgpETN8XxThZHzXFRokuyR3Aza41/p3eg/jo07DGmUBLRP2 |
| 74 |
fu9h/ZVwrcPixgpTNd2+8YhxIxuoka7CmJiVb4ncAJ/Yp95G64dM57DXf46rKPTC |
| 75 |
6LX/5jQgXcR+WbQswLumZJ+EJ7aIzGhJRFGXZmbNvWVrzFxfB7vtgUl6NUsKmzTo |
| 76 |
gffrxrZexzlnvkCThrdM1C89BdAdkWATICiAAEkf2P9gzEdtB+p65VBqYcNzFc+Q |
| 77 |
X9kw+X6lnAn6D/KqJdSAG9plhjRuZ9JTGnZ/ZlucyP7uVnmHV5+NOVn5MYvZ/Sso |
| 78 |
z2F4QPIJi3C9LQkOSyKF |
| 79 |
=vy05 |
| 80 |
-----END PGP SIGNATURE----- |
Archives