Gentoo Archives: gentoo-dev

From: "Rick \\\"Zero_Chaos\\\" Farina" <zerochaos@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
Date: Tue, 04 Sep 2012 20:04:38
Message-Id: 50465F27.90606@gentoo.org
In Reply to: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching by Ian Stakenvicius
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On 09/04/2012 03:56 PM, Ian Stakenvicius wrote:
5 > On 04/09/12 01:32 PM, Zac Medico wrote:
6 >> On 09/04/2012 10:05 AM, Rick "Zero_Chaos" Farina wrote:
7 >>> I believe the easiest (and honestly most sane) method is to
8 >>> simply have src_fetch in the live classes check for needed deps
9 >>> and die (with a "please emerge blah") if deps are not found.
10 >>> Adding something like FDEPEND just seems to be getting way too
11 >>> crazy on the dependency tree AND would require things to build
12 >>> during fetch-only which doesn't make sense.
13 >
14 >> I think it's nicer to have FDEPEND because it makes the deps more
15 >> complete, so the package manager can bail out when necessary,
16 >> without even executing src_fetch. In the case of --fetchonly the
17 >> package manager could simply bail out if the deps are not installed
18 >> (like how it bails out for --buildpkgonly when the deps aren't
19 >> installed).
20 >
21 > Just looking into the future here; would things like archivers or
22 > other helpers used by src_unpack move to FDEPEND as well? or would
23 > this be limited solely to tools that data transfer?
24
25 We are talking about things required for src_fetch (the download) so no,
26 things required for src_unpack have no real place in this as far as I am
27 concerned.
28 >
29 >
30 >
31 >
32 >
33
34 -----BEGIN PGP SIGNATURE-----
35 Version: GnuPG v2.0.19 (GNU/Linux)
36 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
37
38 iQIcBAEBAgAGBQJQRl8nAAoJEKXdFCfdEflKoA0P/152JYx2/62tou9kcUCEILkz
39 DXGfO5bY+A1DYrCsVAR9H7C4dzmrULU0JNjUl3nMpGFKXMAvWQbai2uDICMECZVg
40 QCwHVzxyHD9TzdVAyp928dtn/FtnPvaUV8WHIugFuaZZM/mmACsyEYxFqusMXu51
41 KkMzs1F9TatL3uoAMuvT0KLiMWHmxw6OrmMrqRX1T7gP4AIy7cD5h8v7DOzWORLQ
42 x12/HGAA2HLDgfhwrNymRs+OIqSLXE54DmAfvOglB6Jfw/I/N6HoY1PQ1vZaW7jU
43 P+t2l7VbRsINmHUk+tbl+7A5F2XBE5GphSh8oIN7yuToSwtbstlGFmTGhb/V0gpM
44 HUpI5v/6B40fc+DgEuAMAZjhUBT+1YIbIO9WVUaXN/I9JBA22FBZSm4qu59qWg/U
45 DX+Jhul9M+A5QPdNBios0K5BYxFXamx/i52w/361NdLV2Onn1zHQT95oC7RKOGJG
46 fZu6PhtkW7Z/CaYSja7TKa8H5pl/+Bj5Mgz7cGlwz41AP4Q6+omfnxlLf+iJME07
47 rBfKe4RuhZuUXamu+SfW7OdNY8Zqm9skSGw1HbHFVHDQIXKtt8Pv9tr1m364h+W9
48 r6SUE1xdJaCbtzh2/ajpu9EIVLoVuW/NEFvQIMd7wn3R2PTKgNHOnkLB6c8j/qaa
49 nWe+jCpIt2uSd2Syceqh
50 =4kd2
51 -----END PGP SIGNATURE-----