1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 27/08/13 06:01 AM, Michał Górny wrote: |
5 |
> Hello, all. |
6 |
> |
7 |
> As the next item for discussion in EAPI 6 I'd like to raise the |
8 |
> idea of introducing src_fetch() phase for fetching live sources. |
9 |
> |
10 |
> First of all, I'd like to emphasize that the additional phase |
11 |
> function will not make live ebuilds any more welcome than they are |
12 |
> now. They will still be discouraged, and subject to masking as |
13 |
> usual. However, the function will improve the experience of users |
14 |
> using them. |
15 |
> |
16 |
> The major goal is to add a src_fetch() phase that could be called |
17 |
> earlier during the ebuild process (e.g. within a parallel fetching |
18 |
> process) or in a 'emerge --fetchonly' or similar call. |
19 |
> |
20 |
> I will sum up the issues that came up already. However, feel free |
21 |
> to point out any more questions if you have some. |
22 |
> |
23 |
|
24 |
0. Why src_fetch() instead of pkg_fetch() ? Technically this would |
25 |
be running based on the package and may not even need to touch ${S} if |
26 |
the implementation just handles getting the sources to a state where a |
27 |
src_unpack() can copy them over. Being a pkg_* would also keep it out |
28 |
of the standbox (as i believe convention is that all src_* are |
29 |
supposed to be sandboxed, correct??) |
30 |
|
31 |
|
32 |
|
33 |
> |
34 |
> 1. How should we state fetch dependencies? |
35 |
> |
36 |
> Most of live ebuilds would need a dependency on the VCS they're |
37 |
> using. Currently, those dependencies are part of DEPEND. However, |
38 |
> if src_fetch() is done early or out-of-process, it will no longer |
39 |
> be good enough for us. |
40 |
> |
41 |
> I see two major directions here: |
42 |
> |
43 |
> a) explicitly stating fetch dependencies (as FDEPEND or using |
44 |
> magical USE flag thingie in DEPEND). Then, those dependencies would |
45 |
> be pulled in earlier than other DEPENDs and installed before |
46 |
> src_fetch() is called. |
47 |
> |
48 |
> I think this will require more work on Zac's side. Also, should we |
49 |
> then install VCS-es during 'emerge --fetchonly'? |
50 |
> |
51 |
|
52 |
This could be handled via support from the PM, too. IE, if you want |
53 |
to be able to install git-based live ebuilds either install git by |
54 |
hand or have USE="git" enabled on portage/paludis/etc. |
55 |
|
56 |
Either way, it does make sense to have the fetcher (and by extension, |
57 |
possibly also the unarchiver??) as a separate dependency type instead |
58 |
of being in DEPEND, since these would technically be packages that the |
59 |
PM itself needs now to do its thing rather than the software package. |
60 |
|
61 |
|
62 |
> 2. Should src_unpack() be disallowed from fetching VCS sources? |
63 |
> |
64 |
> If we introduce src_fetch() in EAPI 6, then we should probably |
65 |
> expect all the live eclasses to use that rather than src_unpack() |
66 |
> for fetching. If we agree on this, we can extend portage's |
67 |
> network-sandbox to this phase, and likely filesystem sandbox as |
68 |
> well. |
69 |
> |
70 |
|
71 |
The portage network-sandbox feature is going to have to act in an |
72 |
EAPI-specific way -- ie, there's still plenty of EAPI5 and lower |
73 |
ebuilds that will inherit say, git-2.eclass and therefore that eclass |
74 |
will still need to support doing its bits in src_unpack. |
75 |
|
76 |
|
77 |
> 3. Is everyone ok with splitting VCS fetch into fetch+unpack? |
78 |
> |
79 |
> That is, the new design would be like: |
80 |
> |
81 |
> - src_fetch() fetches the updates from remote server to DISTDIR, |
82 |
> |
83 |
> - src_unpack() does the checkout from DISTDIR to S. |
84 |
> |
85 |
> I suspect that some live ebuilds may prefer different kind of |
86 |
> operation but this split seems quite reasonable. |
87 |
|
88 |
This implementation makes a lot of sense to me. In terms of the |
89 |
specific implementation, I assume both src_fetch and src_unpack be |
90 |
imeplemented in i.e. git-2.eclass? Or would there be an accompanying |
91 |
change to the default src_unpack behaviour to, say, '[[ -z $A ]] && cp |
92 |
- -r ${VCSDIR} ${S}' for EAPI6 ? |
93 |
|
94 |
|
95 |
|
96 |
-----BEGIN PGP SIGNATURE----- |
97 |
Version: GnuPG v2.0.20 (GNU/Linux) |
98 |
|
99 |
iF4EAREIAAYFAlIcuLcACgkQ2ugaI38ACPC9GgD/XgCI8G1+eQj4ccxYmSf+TySh |
100 |
dKvqpvD/Eorq9PfvDqEBAI8o1ChnvfBdDpQ4tNBGlLmGDK0E6Ba3UDTE6xSFnXZ6 |
101 |
=afLt |
102 |
-----END PGP SIGNATURE----- |