Hello, all. As the next item for discussion in EAPI 6 I'd like to raise the idea of introducing src_fetch() phase for fetching live sources.
First of all, I'd like to emphasize that the additional phase function will not make live ebuilds any more welcome than they are now. They will still be discouraged, and subject to masking as usual. However, the function will improve the experience of users using them. The major goal is to add a src_fetch() phase that could be called earlier during the ebuild process (e.g. within a parallel fetching process) or in a 'emerge --fetchonly' or similar call. I will sum up the issues that came up already. However, feel free to point out any more questions if you have some. 1. How should we state fetch dependencies? Most of live ebuilds would need a dependency on the VCS they're using. Currently, those dependencies are part of DEPEND. However, if src_fetch() is done early or out-of-process, it will no longer be good enough for us. I see two major directions here: a) explicitly stating fetch dependencies (as FDEPEND or using magical USE flag thingie in DEPEND). Then, those dependencies would be pulled in earlier than other DEPENDs and installed before src_fetch() is called. I think this will require more work on Zac's side. Also, should we then install VCS-es during 'emerge --fetchonly'? b) assume that early src_fetch() is allowed to fail and retry before build. This is much like what portage does anyway. If VCS is not installed yet during parallel fetch or --fetchonly, the particular fetch fails like it can fail due to 404. When the actual build process starts, emerge calls src_fetch() again much like it currently retries fetching missing SRC_URI items. This would be simpler. We could probably cache the src_fetch() result (if possible) to avoid double-fetching. Or just accept the minimal overhead of plain update check. 2. Should src_unpack() be disallowed from fetching VCS sources? If we introduce src_fetch() in EAPI 6, then we should probably expect all the live eclasses to use that rather than src_unpack() for fetching. If we agree on this, we can extend portage's network-sandbox to this phase, and likely filesystem sandbox as well. 3. Is everyone ok with splitting VCS fetch into fetch+unpack? That is, the new design would be like: - src_fetch() fetches the updates from remote server to DISTDIR, - src_unpack() does the checkout from DISTDIR to S. I suspect that some live ebuilds may prefer different kind of operation but this split seems quite reasonable. Relevant bugs: - https://bugs.gentoo.org/show_bug.cgi?id=182028 - https://bugs.gentoo.org/show_bug.cgi?id=481434 -- Best regards, Michał Górny
signature.asc
Description: PGP signature
