1 |
On 4/23/19 6:25 PM, Zac Medico wrote: |
2 |
> |
3 |
> Note that systemd.eclass is lighter on dependencies, which is why I |
4 |
> chose it for the solution to bug 490676 [1] and bug 643386 [2] in the |
5 |
> sys-apps/portage ebuilds. |
6 |
> |
7 |
> [1] https://bugs.gentoo.org/490676 |
8 |
> [2] https://bugs.gentoo.org/643386 |
9 |
> |
10 |
|
11 |
I think that's an illusion. The two eclasses should really have the same |
12 |
dependencies because they do exactly the same thing. |
13 |
|
14 |
Obviously we don't want to pull in systemd when people inherit the |
15 |
systemd.eclass, so there are guards around every use of a systemd |
16 |
program, such as |
17 |
|
18 |
systemd_reenable() { |
19 |
type systemctl &>/dev/null || return 0 |
20 |
... |
21 |
} |
22 |
|
23 |
Likewise, the only function in tmpfiles.eclass that uses a systemd or |
24 |
opentmpfiles program is |
25 |
|
26 |
tmpfiles_process() { |
27 |
... |
28 |
if type systemd-tmpfiles &> /dev/null; then |
29 |
systemd-tmpfiles --create "$@" |
30 |
elif type tmpfiles &> /dev/null; then |
31 |
tmpfiles --create "$@" |
32 |
fi |
33 |
... |
34 |
} |
35 |
|
36 |
which will still work (albeit with a warning) if you somehow manage not |
37 |
to have virtual/tmpfiles installed. So, if it's important, I think we |
38 |
could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass. |