On Fri, 2019-04-26 at 10:26 -0400, Michael Orlitzky wrote: > On 4/26/19 9:32 AM, Michał Górny wrote: > > Whether it can be deleted is up to system's configuration. The current > > solution works for majority of cases, including a. people who use > > systemd or OpenRC, and set their systems to clean it up, and b. people > > who don't use either but don't clean it up. > > > > We can't support everyone, and a small potential minority for whose this > > might not work is no excuse to replace it with a worse solution. > > > > https://www.youtube.com/watch?v=yjfrJzdx7DA > > I don't believe that one of the world's foremost experts on package > management is stumped trying to configure a common cache directory. But, > I've let you change the subject. > > We're only talking about eix because you gave it as an example of a > package that needs the RDEPEND=virtual/tmpfiles in the eclass, claiming > that it needs tmpfiles_process() to work. Yet you've acknowledged that > this is an eix-specific hack that won't work in some cases. > > 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. > 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, and (b) it requires you to reinstall the package every time the directory might disappear. > Both are preferable in the case of app-portage/eix, so I don't buy it as > justification for keeping the RDEPEND in the eclass. Are there better > examples? I'm sorry but this is getting silly. I've provided you with the rationale and with an example. I'm not going to spend half of the day trying to throw more and more examples, so that you'd keep rejecting them, and in the end claim that I haven't provided any justification because you rejected everything. The data you have should be entirely sufficient to understand how things work. If you disagree with it, that's your right. However, your weak counter-arguments aren't going to convince me, and I don't see any purpose in bringing more arguments because I really do see where this is going. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
