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 ACCD9138010 for ; Tue, 4 Sep 2012 17:22:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9E3CCE04EC; Tue, 4 Sep 2012 17:22:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E26AFE032F for ; Tue, 4 Sep 2012 17:21:48 +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 3EC8633D791 for ; Tue, 4 Sep 2012 17:21:48 +0000 (UTC) Message-ID: <5046393D.5070901@gentoo.org> Date: Tue, 04 Sep 2012 13:24:13 -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: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 3ef5cc5a-50b3-4afc-a59c-c0ccad313928 X-Archives-Hash: 0d833cae6ef8be01a67eaf29a67178b5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/2012 01:02 PM, Michael Mol wrote: > On Tue, Sep 4, 2012 at 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 'checking out' language for src_unpack() sounds like it assumes a > DVCS such as mercurial or git. What about cvs or svn, where fetching > is also checking out? (This is probably a trivial thing to clear up, > though.) > > Also, where would the local copy go? distfiles? It's common for > distfiles to be stored on, e.g. an NFS mount, so you may need to be > careful not to place repositories there which have filesystem > semantics that are disagreeable to NFS. (The only example I know of > off the top of my head is svn, where the documentation warns against > using the dbd backend on top of NFS.) > > Other common remote mounts (such as cifs) may have restrictions that > could force munging of filenames, too, and VCS infrastructures (or > even unpacked checkouts with strange filenames) placed on those > filesystems may have unanticipated results. > > It may be helpful to have some kind of adapter mount in place, or even > generate a tarball of the local copy and store that instead. (That'd > be problematic if multiple boxes were modifying the local copy on the > same share, but that's obviously problematic anyway.) > All the live eclasses already drop a checkout (or whatever term you like) of the repo in /usr/portage/distfiles. What we are talking about here is separating the "download/checkout into /usr/portage/distfiles" from the "copy from /usr/portage/distfiles to ${S}". Making this two separate phases would allow a reasonably sane "emerge -f blah" support to fetch the live sources before build. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRjk9AAoJEKXdFCfdEflKeocQAJgSMaycMkvmdalYWUBU4lRJ eNilSxWoMAuln+1FMRv9HxavQCMzkw/h9o3Lwy75Kv2+Z/MZy60caG7yplexSKEf Z3apTwU1Cbj7WasDNkNRXgoHHsn55Fnr28lueFmcAlvMWDnBV0TmXCYFiRh961hN 7Co3wbHT4ahk1TTTURFDoWbE2R24e1UJFzrWRRO4oyoIDqPqOIOqhR+4Nnl5vsXa /UQmvIqgzxlWgdjeaWceQxgexPt0g+ZwFUFIF6FhL3xqoF6kokBj64VxPRAgK05X x78LSsul+A0H6sAU4S9e5CmZekxFyNanF3PJ5aZaAfp8dPTWaUFIhJHh3jDFktdT zaO1LVpEOVnUenuV6XgpETN8XxThZHzXFRokuyR3Aza41/p3eg/jo07DGmUBLRP2 fu9h/ZVwrcPixgpTNd2+8YhxIxuoka7CmJiVb4ncAJ/Yp95G64dM57DXf46rKPTC 6LX/5jQgXcR+WbQswLumZJ+EJ7aIzGhJRFGXZmbNvWVrzFxfB7vtgUl6NUsKmzTo gffrxrZexzlnvkCThrdM1C89BdAdkWATICiAAEkf2P9gzEdtB+p65VBqYcNzFc+Q X9kw+X6lnAn6D/KqJdSAG9plhjRuZ9JTGnZ/ZlucyP7uVnmHV5+NOVn5MYvZ/Sso z2F4QPIJi3C9LQkOSyKF =vy05 -----END PGP SIGNATURE-----