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 F22A9138010 for ; Tue, 4 Sep 2012 16:43:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83DC3E0369; Tue, 4 Sep 2012 16:43:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 83A00E00AB for ; Tue, 4 Sep 2012 16:42:50 +0000 (UTC) Received: from pomiocik.lan (213-238-98-26.adsl.inetia.pl [213.238.98.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 029FF33D722; Tue, 4 Sep 2012 16:42:48 +0000 (UTC) Date: Tue, 4 Sep 2012 18:43:45 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching Message-ID: <20120904184345.77696965@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/jdNJRcHpc4CnhfGb.+g.UQP"; protocol="application/pgp-signature" X-Archives-Salt: f1777cac-020e-4820-9104-0132f34fea6f X-Archives-Hash: f1a8767ff2d1d6065644d2cc2737175d --Sig_/jdNJRcHpc4CnhfGb.+g.UQP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3Duserfetch 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? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/jdNJRcHpc4CnhfGb.+g.UQP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlBGL8YACgkQfXuS5UK5QB2l0gP8Dz1/tJbqiPqCpQ3XeLbStPLW y4IpFRMyeOwF8SBwgwMd35AtPixxczu5vObv9tdhAISOEFIoS/UNOEAc6lQ+zxsE EA5I0o0qYbwRWFVtBtD2d3wQxFdgYBBrwm9KNXf4PHoaFyBTRWgcSQQhYrs71yn7 8q1dhuzm4+0Dcw8JGe0= =ETuN -----END PGP SIGNATURE----- --Sig_/jdNJRcHpc4CnhfGb.+g.UQP--