On 8/27/13 3:01 AM, Michał Górny wrote: > 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.
I think b) is better. Having a USE flag with a special meaning sounds bad; adding FDEPEND could be reasonable, but then --fetchonly behavior may become counter-intuitive. It seems to me b) is the most reasonable option, and also has the advantage of being simpler as you've said. > 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. I'm fine with this and think it's a good idea, but it's kind of secondary - things will still "work" whether or not we do that. Paweł
signature.asc
Description: OpenPGP digital signature
