Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
Date: Fri, 26 Apr 2019 16:07:34
Message-Id: 1406866d-16b5-1c50-fc64-52a5792defde@gentoo.org
In Reply to: Re: [gentoo-dev] What's going on with the tmpfiles eclasses? by "Michał Górny"
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.