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 60523138010 for ; Tue, 4 Sep 2012 17:04:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 50578E04BA; Tue, 4 Sep 2012 17:03:47 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id CA9A9E0459 for ; Tue, 4 Sep 2012 17:02:37 +0000 (UTC) Received: by bkwj4 with SMTP id j4so2889812bkw.40 for ; Tue, 04 Sep 2012 10:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=3KlYQ1d1SO5MZAf9chfit1r/qr+x1TgcG6twNVqX61c=; b=q6qNUM+WLlAB4DkPTMTKmeF8vPtHV5gfirdUH8KQo8YIJgD4n29xbweXOFKZAs53jb XJbTmjZZb+iodT3AfFqG32aZDerAWl+rJgQp82+G7eu5lF59+fVy9pwhzUX+npkIpc4P 42LVWZWV99hOQtFPfrt7ApY0xg5MQx9lwI0N81p2Q2yBXK/kjmJEghAmIVDMt34bta4T ZVXdBhEa7BrIikVG4/ZaMvz+SldsgqTNZP2qGkAPtOlDJUBrv9xA4HN+sYPBz//uKKXK tUCYbYYz0C3WHXHcHS6jLQmsiTvwcNgaMg0B5dtBOyzDbWMQL2f5E/dv/8zIgZZYLEoV op7Q== 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 Received: by 10.205.133.11 with SMTP id hw11mr8654874bkc.46.1346778156891; Tue, 04 Sep 2012 10:02:36 -0700 (PDT) Received: by 10.204.112.211 with HTTP; Tue, 4 Sep 2012 10:02:36 -0700 (PDT) In-Reply-To: <20120904184345.77696965@pomiocik.lan> References: <20120904184345.77696965@pomiocik.lan> Date: Tue, 4 Sep 2012 13:02:36 -0400 Message-ID: Subject: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching From: Michael Mol To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 3cc3a186-75a0-43f5-b32b-4d786dc9bcb4 X-Archives-Hash: c6e11e32cc87fec1d2f7cc6e96c570b6 On Tue, Sep 4, 2012 at 12:43 PM, Micha=C5=82 G=C3=B3rny = 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=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 '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.) --=20 :wq