[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
From:       Michael Orlitzky <mjo () gentoo ! org>
Date:       2019-04-26 16:07:23
Message-ID: 1406866d-16b5-1c50-fc64-52a5792defde () gentoo ! org
[Download RAW message or body]

On 4/26/19 10:54 AM, Michał Górny wrote:
>>
>> In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
>> better solution, because (a) the end result is exactly the same, (b) it
>> keeps the dependency out of the eclass, and (c) it localizes the
>> dependency to the place that needs it, namely the wacky package.
> 
> Maybe.  However, as I already said, we have determined that (a) it is
> easier for devs to have the dep in eclass, and (b) it doesn't hurt.  If
> you are really a tmpfiles hater, you can use package.provided and stop
> harming users through being absurdly pedantic.
> 

This isn't about hating tmpfiles. In my original message, I asked why we 
couldn't replace the systemd_* implementations with the ones from 
tmpfiles.eclass. Apparently there's only one reason, given by Zac: the 
extraneous RDEPEND in the tmpfiles eclass. My goal here is to clean up 
our eclasses, not complain about tmpfiles.

Ease of use is irrelevant if the dependency is wrong, and "it doesn't 
hurt" is clearly false because it's preventing us from deleting a bunch 
of copy/pasted code.


>> In cases like that, using a simple "dodir /var/cache/eix" is a better
>> solution because (a) the end result is exactly the same, (b) it keeps
>> the dependency out of the eclass, and (c) doesn't need a dependency on
>> virtual/tmpfiles at all.
> 
> No, it isn't 'exactly the same'.  (a) it doesn't set correct
> permissions,

An irrelevant detail. Set them to whatever you like in the ebuild.


> and (b) it requires you to reinstall the package every time
> the directory might disappear.

That's how it works now.

[prev in list] [next in list] [prev in thread] [next in thread]