1 |
On 4/26/19 10:54 AM, Michał Górny wrote: |
2 |
>> |
3 |
>> In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a |
4 |
>> better solution, because (a) the end result is exactly the same, (b) it |
5 |
>> keeps the dependency out of the eclass, and (c) it localizes the |
6 |
>> dependency to the place that needs it, namely the wacky package. |
7 |
> |
8 |
> Maybe. However, as I already said, we have determined that (a) it is |
9 |
> easier for devs to have the dep in eclass, and (b) it doesn't hurt. If |
10 |
> you are really a tmpfiles hater, you can use package.provided and stop |
11 |
> harming users through being absurdly pedantic. |
12 |
> |
13 |
|
14 |
This isn't about hating tmpfiles. In my original message, I asked why we |
15 |
couldn't replace the systemd_* implementations with the ones from |
16 |
tmpfiles.eclass. Apparently there's only one reason, given by Zac: the |
17 |
extraneous RDEPEND in the tmpfiles eclass. My goal here is to clean up |
18 |
our eclasses, not complain about tmpfiles. |
19 |
|
20 |
Ease of use is irrelevant if the dependency is wrong, and "it doesn't |
21 |
hurt" is clearly false because it's preventing us from deleting a bunch |
22 |
of copy/pasted code. |
23 |
|
24 |
|
25 |
>> In cases like that, using a simple "dodir /var/cache/eix" is a better |
26 |
>> solution because (a) the end result is exactly the same, (b) it keeps |
27 |
>> the dependency out of the eclass, and (c) doesn't need a dependency on |
28 |
>> virtual/tmpfiles at all. |
29 |
> |
30 |
> No, it isn't 'exactly the same'. (a) it doesn't set correct |
31 |
> permissions, |
32 |
|
33 |
An irrelevant detail. Set them to whatever you like in the ebuild. |
34 |
|
35 |
|
36 |
> and (b) it requires you to reinstall the package every time |
37 |
> the directory might disappear. |
38 |
|
39 |
That's how it works now. |