1 |
On 4/26/19 9:32 AM, Michał Górny wrote: |
2 |
> |
3 |
> Whether it can be deleted is up to system's configuration. The current |
4 |
> solution works for majority of cases, including a. people who use |
5 |
> systemd or OpenRC, and set their systems to clean it up, and b. people |
6 |
> who don't use either but don't clean it up. |
7 |
> |
8 |
> We can't support everyone, and a small potential minority for whose this |
9 |
> might not work is no excuse to replace it with a worse solution. |
10 |
> |
11 |
|
12 |
https://www.youtube.com/watch?v=yjfrJzdx7DA |
13 |
|
14 |
I don't believe that one of the world's foremost experts on package |
15 |
management is stumped trying to configure a common cache directory. But, |
16 |
I've let you change the subject. |
17 |
|
18 |
We're only talking about eix because you gave it as an example of a |
19 |
package that needs the RDEPEND=virtual/tmpfiles in the eclass, claiming |
20 |
that it needs tmpfiles_process() to work. Yet you've acknowledged that |
21 |
this is an eix-specific hack that won't work in some cases. |
22 |
|
23 |
In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a |
24 |
better solution, because (a) the end result is exactly the same, (b) it |
25 |
keeps the dependency out of the eclass, and (c) it localizes the |
26 |
dependency to the place that needs it, namely the wacky package. |
27 |
|
28 |
In cases like that, using a simple "dodir /var/cache/eix" is a better |
29 |
solution because (a) the end result is exactly the same, (b) it keeps |
30 |
the dependency out of the eclass, and (c) doesn't need a dependency on |
31 |
virtual/tmpfiles at all. |
32 |
|
33 |
Both are preferable in the case of app-portage/eix, so I don't buy it as |
34 |
justification for keeping the RDEPEND in the eclass. Are there better |
35 |
examples? |