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 0DE0D138010 for ; Tue, 4 Sep 2012 17:05:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5FDFE04BA; Tue, 4 Sep 2012 17:04:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6D5C0E0458 for ; Tue, 4 Sep 2012 17:03:19 +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 A103F33D738 for ; Tue, 4 Sep 2012 17:03:13 +0000 (UTC) Message-ID: <504634E3.7070002@gentoo.org> Date: Tue, 04 Sep 2012 13:05:39 -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: 1300605a-d0bf-41b4-8d84-202a8e93afc2 X-Archives-Hash: f603fb1d6121da62e8aabad939dbb2fa -----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-----