1 |
On Thu, 2019-12-19 at 20:40 +0100, Michał Górny wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Here's another potential EAPI 8 feature I'd like to discuss. Please |
5 |
> note that this is about *new dependency type*, so please don't hijack |
6 |
> it |
7 |
> into the big 'let's steal Exherbo syntax' debate. |
8 |
> |
9 |
> Bug: https://bugs.gentoo.org/660306 |
10 |
> |
11 |
> |
12 |
> The problem |
13 |
> =========== |
14 |
> |
15 |
> Right now we don't really have a clean way of specifying dependencies |
16 |
> that are used during pkg_*inst (and pkg_*rm?) phases. So far RDEPEND |
17 |
> was used as a 'close enough' alternative (except for a few developers |
18 |
> who rejected it as 'invalid' and used DEPEND which is even more |
19 |
> wrong). |
20 |
> However, this is no longer sufficient with EAPI 7 cross support. |
21 |
> |
22 |
> By design, pkg_*inst phases are run in build host's environment when |
23 |
> cross is used (because obviously you can't run target host |
24 |
> executables). |
25 |
> Therefore, the relevant dependencies need to be installed into CBUILD |
26 |
> root, while RDEPEND is installed into CHOST root. |
27 |
> |
28 |
> |
29 |
> The proposed solution |
30 |
> ===================== |
31 |
> |
32 |
> The proposal is to add a new dependency type (codename: IDEPEND) |
33 |
> which |
34 |
> indicates dependencies used for pkg_*inst (and pkg_*rm?) |
35 |
> phases. Those |
36 |
> dependencies would be installed into CBUILD root (like BDEPEND), and |
37 |
> therefore would be runnable from build host. Similarly to RDEPEND, |
38 |
> they |
39 |
> would be installed for binary package installs but not for pure |
40 |
> binpkg |
41 |
> builds (without install). |
42 |
> |
43 |
> Example: |
44 |
> |
45 |
> inherit xdg-utils |
46 |
> |
47 |
> IDEPEND="dev-util/desktop-file-utils" |
48 |
> |
49 |
> pkg_postinst() { |
50 |
> xdg_desktop_database_update |
51 |
> } |
52 |
> |
53 |
> |
54 |
> WDYT? |
55 |
> |
56 |
|
57 |
|
58 |
Should we use this to drop RDEPEND from pkg_*inst/rm phases ? |
59 |
PMS states "RDEPEND (unless the particular dependency results in a |
60 |
circular dependency, in which case it may be installed later)" which is |
61 |
kind of "maybe maybe not" and I'm not sure how one can rely on RDEPEND |
62 |
for those phases in their ebuilds if another random ebuild can trigger |
63 |
a case where it's not satisfied. |