-----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 If you insist on using real names mine is Rick ;-) > 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(). > > 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/ iQIcBAEBAgAGBQJQRjQeAAoJEKXdFCfdEflKdDAP/jyV8+NwEBX+etKq7e+qzbVg oIgjqOLfqYEmbEkO9WMsUltsf8YATy9zGB1itRiLUb5v+eptjEDvp2dx/AA4YVio RLYwtMBJsESXd6d+3PbCTeoZHTZwb7ue6yY+qC0auyC4mD6nrkDY8swungcDwFHN GZ99gAtRnQ5h8+phrKHyWzePTkBN5+32GCIn2XfRwMo+T0tGyTeMGqYfPJPlEu0y LNJmdBU0TfzE7N8QA4sp/IDQQvBmZNpH6aQM+zkJWpvBUXBATdIPZZHBAy55TWaJ t9KxiHD6XF/h0ShlTIpsbfSj31FTil2l/LfhAQdXSrB4GPxLaoovOJb2vl9L+ZyP QJclNeL1kNaOO1MIm20tGJOV6Wh0iHsn/fJlbh4YYn4PaNF+F+UXyp69uGcniuCe PxFC/aosq39LoFRrZdyRfx3DWPXnhYfcFWRwEDosa/Qb/Mbljs+BZRRPIB2Y8ItV 9j5WokM6BkNPNeoNnaS1JvCaac7xiurizs7IaXxfYC5q8aZja1OdDrV9Jh7KxIUe q8rsKMk6y9KqGvSBfW3Y9JDgIdUUG8x0bVM/j9+gqOtPH5uFgPRnZxX/Hfb0+1J5 iLjFXgwLl2AtEuflY07KfKB9xyEV58x8gkCo/BUX8Y8E6re5/4o+kNiArQL2Z+YS SOD2BmvyVHOlurug9Lq4 =FOao -----END PGP SIGNATURE-----
