| 1 |
Hello, all. |
| 2 |
|
| 3 |
As the next item for discussion in EAPI 6 I'd like to raise the idea of |
| 4 |
introducing src_fetch() phase for fetching live sources. |
| 5 |
|
| 6 |
First of all, I'd like to emphasize that the additional phase function |
| 7 |
will not make live ebuilds any more welcome than they are now. They |
| 8 |
will still be discouraged, and subject to masking as usual. However, |
| 9 |
the function will improve the experience of users using them. |
| 10 |
|
| 11 |
The major goal is to add a src_fetch() phase that could be called |
| 12 |
earlier during the ebuild process (e.g. within a parallel fetching |
| 13 |
process) or in a 'emerge --fetchonly' or similar call. |
| 14 |
|
| 15 |
I will sum up the issues that came up already. However, feel free to |
| 16 |
point out any more questions if you have some. |
| 17 |
|
| 18 |
|
| 19 |
1. How should we state fetch dependencies? |
| 20 |
|
| 21 |
Most of live ebuilds would need a dependency on the VCS they're using. |
| 22 |
Currently, those dependencies are part of DEPEND. However, if |
| 23 |
src_fetch() is done early or out-of-process, it will no longer be good |
| 24 |
enough for us. |
| 25 |
|
| 26 |
I see two major directions here: |
| 27 |
|
| 28 |
a) explicitly stating fetch dependencies (as FDEPEND or using |
| 29 |
magical USE flag thingie in DEPEND). Then, those dependencies would be |
| 30 |
pulled in earlier than other DEPENDs and installed before src_fetch() |
| 31 |
is called. |
| 32 |
|
| 33 |
I think this will require more work on Zac's side. Also, should we then |
| 34 |
install VCS-es during 'emerge --fetchonly'? |
| 35 |
|
| 36 |
b) assume that early src_fetch() is allowed to fail and retry before |
| 37 |
build. This is much like what portage does anyway. If VCS is not |
| 38 |
installed yet during parallel fetch or --fetchonly, the particular |
| 39 |
fetch fails like it can fail due to 404. When the actual build process |
| 40 |
starts, emerge calls src_fetch() again much like it currently retries |
| 41 |
fetching missing SRC_URI items. |
| 42 |
|
| 43 |
This would be simpler. We could probably cache the src_fetch() result |
| 44 |
(if possible) to avoid double-fetching. Or just accept the minimal |
| 45 |
overhead of plain update check. |
| 46 |
|
| 47 |
|
| 48 |
2. Should src_unpack() be disallowed from fetching VCS sources? |
| 49 |
|
| 50 |
If we introduce src_fetch() in EAPI 6, then we should probably expect |
| 51 |
all the live eclasses to use that rather than src_unpack() for |
| 52 |
fetching. If we agree on this, we can extend portage's network-sandbox |
| 53 |
to this phase, and likely filesystem sandbox as well. |
| 54 |
|
| 55 |
|
| 56 |
3. Is everyone ok with splitting VCS fetch into fetch+unpack? |
| 57 |
|
| 58 |
That is, the new design would be like: |
| 59 |
|
| 60 |
- src_fetch() fetches the updates from remote server to DISTDIR, |
| 61 |
|
| 62 |
- src_unpack() does the checkout from DISTDIR to S. |
| 63 |
|
| 64 |
I suspect that some live ebuilds may prefer different kind of operation |
| 65 |
but this split seems quite reasonable. |
| 66 |
|
| 67 |
|
| 68 |
Relevant bugs: |
| 69 |
- https://bugs.gentoo.org/show_bug.cgi?id=182028 |
| 70 |
- https://bugs.gentoo.org/show_bug.cgi?id=481434 |
| 71 |
|
| 72 |
-- |
| 73 |
Best regards, |
| 74 |
Michał Górny |
Archives