From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4C963138010 for ; Tue, 4 Sep 2012 17:01:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58E04E0369; Tue, 4 Sep 2012 17:00:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C2EA1E019D for ; Tue, 4 Sep 2012 16:59:57 +0000 (UTC) Received: from [192.168.1.12] (pool-71-245-176-92.pitbpa.fios.verizon.net [71.245.176.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id 29C8633D780 for ; Tue, 4 Sep 2012 16:59:57 +0000 (UTC) Message-ID: <5046341E.5050209@gentoo.org> Date: Tue, 04 Sep 2012 13:02:22 -0400 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120815 Thunderbird/14.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching References: <20120904184345.77696965@pomiocik.lan> In-Reply-To: <20120904184345.77696965@pomiocik.lan> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: dba66f72-a158-4928-8bb7-7aedd3c2c758 X-Archives-Hash: 7bc69611b7f55a5119a2aee39dc51658 -----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-----