Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching

[Rick \\\"Zero_Chaos\\\" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/04/2012 12:43 PM, Michał Górny 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 remaining issue is handling dependencies on the tools necessary to
> do fetching. For default_src_fetch(), we can assume that the package
> manager provides the necessary tools. For custom src_fetch(), we would
> need either to:
>
> 1) require satisfying whole DEPEND when fetching -- probably pointless,
>    as it will make --fetchonly almost impossible when doing initial
>    installs;
>
> 2) introduce a new dependency type (please do not get into details how
>    we do it -- we will discuss that another time, at the moment please
>    just keep it as 'new dependency type') -- and we probably end up
>    having a switch for --fetchonly without installing deps (thus
>    omitting packages where they are not satisfied), and with deps;
>
> 3) [ugly!] assume that src_fetch() should check for its deps and fail
>    if they are not satisfied. If that's mostly for live ebuilds, it may
>    be acceptable. Then the package manager will just have one 'fetch
>    failed' on --fetchonly (or early pre-fetch), and it will have to
>    invoke src_fetch() after satisfying the deps, before src_unpack().

I believe the easiest (and honestly most sane) method is to simply have
src_fetch in the live classes check for needed deps and die (with a
"please emerge blah") if deps are not found.  Adding something like
FDEPEND just seems to be getting way too crazy on the dependency tree
AND would require things to build during fetch-only which doesn't make
sense.

Thanks,
Zero
>
> What do you think? What are your ideas, suggestions?
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRjTjAAoJEKXdFCfdEflKGPoP+wYhzeFNcXO9Lv4qm5/oPXuC
RIrCs2q6erWxowFbiTO//XILVbiH1nHBWx/uJV9S0hTM+dBRIh/zZaCXy5PYnLrK
dTKiHgmpNPgTQ41QGI7BZl4lQFGLgGfdJnCncSTLmLZQtMGwXD4jZ8SQ/QE1wbwK
rpHtYQ/Z5kUKFJG25MRFtFZ2ifZQVpVIPmmrFfyDh+1l9Oh8AtF6XKZTriwX1ppG
osPz8jo2XtoYejqvD0kFEZwc5C7FKmULYyrB+tcl5dmOgf60LvcDTBkUGi7U2ewk
DWhVoLX0zXWMZfoEi3c6GRsJgZ81yXIMfPC+SUYipdfBvdH6iWYuxfgJpSioUtbV
s4xC4IyOGQehnt8OAe5PpHHJcqxlDVXidmVz0sKkmJB3dM6rIsamiNZajmKVrnyh
1zle8g4XBP8AFg/fB+OiOSuYNoI5GnC2D/rp7zAtajl+0GtVWvApPUFEa0DP8LlR
bYXMIGpx+LAi9rYlEdNs3tW1C4OVjZpCKYU7cjNO15f2ZOVX4WNmAWtRmpoG6O5l
zL1Mv6DRgdtoITfYfogupZBgjynHsCzKL1Mb2skqtmJ853ZjV4HGgXqxcica12O7
EoJ65EU5rrzCGSUz5rqunNwK9A11VBjxXWJ/e29NKt2vACxRuiwMXkl7EK2a/oCA
pTBk5q6CvQFJCyzw2bee
=ueCf
-----END PGP SIGNATURE-----