1 |
On Fri, 2019-04-26 at 10:26 -0400, Michael Orlitzky wrote: |
2 |
> On 4/26/19 9:32 AM, Michał Górny wrote: |
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 |
Maybe. However, as I already said, we have determined that (a) it is |
29 |
easier for devs to have the dep in eclass, and (b) it doesn't hurt. If |
30 |
you are really a tmpfiles hater, you can use package.provided and stop |
31 |
harming users through being absurdly pedantic. |
32 |
|
33 |
> In cases like that, using a simple "dodir /var/cache/eix" is a better |
34 |
> solution because (a) the end result is exactly the same, (b) it keeps |
35 |
> the dependency out of the eclass, and (c) doesn't need a dependency on |
36 |
> virtual/tmpfiles at all. |
37 |
|
38 |
No, it isn't 'exactly the same'. (a) it doesn't set correct |
39 |
permissions, and (b) it requires you to reinstall the package every time |
40 |
the directory might disappear. |
41 |
|
42 |
> Both are preferable in the case of app-portage/eix, so I don't buy it as |
43 |
> justification for keeping the RDEPEND in the eclass. Are there better |
44 |
> examples? |
45 |
|
46 |
I'm sorry but this is getting silly. I've provided you with |
47 |
the rationale and with an example. I'm not going to spend half of the |
48 |
day trying to throw more and more examples, so that you'd keep rejecting |
49 |
them, and in the end claim that I haven't provided any justification |
50 |
because you rejected everything. |
51 |
|
52 |
The data you have should be entirely sufficient to understand how things |
53 |
work. If you disagree with it, that's your right. However, your weak |
54 |
counter-arguments aren't going to convince me, and I don't see any |
55 |
purpose in bringing more arguments because I really do see where this |
56 |
is going. |
57 |
|
58 |
-- |
59 |
Best regards, |
60 |
Michał Górny |