[gentoo-dev] Last rites: abandoned Java libraries
# Patrice Clement (19 Apr 2019) # Another round of abandoned Java libraries that must go. # Removal in 30 days. dev-java/lucene-analyzers dev-java/sun-java3d-bin dev-java/sun-dtdparser dev-java/stax app-misc/bfm Closes: https://github.com/gentoo/gentoo/pull/11739 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
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.
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
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
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
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. 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. 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?
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On Fri, 2019-04-26 at 09:24 -0400, Michael Orlitzky wrote: > On 4/26/19 9:07 AM, Michał Górny wrote: > > > I don't think so -- not if it needs that tmpfiles > > > entry to be processed every reboot. Thus it should have its own RDEPEND > > > on virtual/tmpfiles, making the one in the eclass redundant. > > > > It doesn't need to be processed every reboot. It needs to be processed > > at least once. Now, if you were doing something fancy like having > > /var/cache on tmpfs, then it would need to be processed on reboot. > > > > If /var/cache/eix can be deleted, then the tmpfiles entry needs to be > processed on every reboot. If /var/cache/eix cannot be deleted, then a > tmpfiles entry is the wrong way to create it: keepdir should be used > instead. 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. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On 4/26/19 9:07 AM, Michał Górny wrote: > >> I don't think so -- not if it needs that tmpfiles >> entry to be processed every reboot. Thus it should have its own RDEPEND >> on virtual/tmpfiles, making the one in the eclass redundant. > > It doesn't need to be processed every reboot. It needs to be processed > at least once. Now, if you were doing something fancy like having > /var/cache on tmpfs, then it would need to be processed on reboot. > If /var/cache/eix can be deleted, then the tmpfiles entry needs to be processed on every reboot. If /var/cache/eix cannot be deleted, then a tmpfiles entry is the wrong way to create it: keepdir should be used instead.
[gentoo-dev] dev-python/djangocms-attributes-field: last rites
# Virgil Dupras (26 Apr 2019) # Should have been removed with django-cms a while back but wasn't. # Removal in 30 days. Bug #683862 dev-python/djangocms-attributes-field pgpvoE5tur7J9.pgp Description: PGP signature
[gentoo-dev] dev-python/yapps: last rites
# Virgil Dupras (26 Apr 2019) # Unmaintained, no revdeps. Removal in 30 days. Bug #618734 dev-python/yapps pgpretAlpgCq_.pgp Description: PGP signature
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On Fri, 2019-04-26 at 07:07 -0400, Michael Orlitzky wrote: > On 4/26/19 12:53 AM, Michał Górny wrote: > > > And the only reason we would need a transient directory created and/or > > > cleaned-up is because one of those service managers is going to start a > > > program that needs it. Two of them can use the tmpfiles mechanism, but > > > the others must handle it on their own: in particular, they don't need > > > tmpfiles_process() to do anything. > > > > > > > No. tmpfiles is also used for programs started directly by user, such > > as eix. > > > > Good example. Does eix work on a machine running something other than > systemd or OpenRC? Yes, it does. > I don't think so -- not if it needs that tmpfiles > entry to be processed every reboot. Thus it should have its own RDEPEND > on virtual/tmpfiles, making the one in the eclass redundant. It doesn't need to be processed every reboot. It needs to be processed at least once. Now, if you were doing something fancy like having /var/cache on tmpfs, then it would need to be processed on reboot. > > I suspect the same is true of any other example. Let's get to the point: > is there a single example of a package that works with runit, sysvinit, > or daemontools but which needs tmpfiles_process() to run? The general assumption we made here is that if you use OpenRC or systemd, you may have fancy stuff like /tmp on tmpfs, and you want tmpfiles processing running every reboot. If you don't, we assume you need to run it at least once, to get the directories initialized. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OT: persistence of directories under /var/cache
On 4/26/19 12:53 AM, Michał Górny wrote: > > No. tmpfiles is also used for programs started directly by user, such > as eix. > This configuration is buggy to begin with: if I run eix-update as my user, then the permissions on the files it creates under /var/cache/eix are wrong (mjo:mjo, mode 664). If I run eix as root and it drops privileges, then the permissions on the files it creates are correct (portage:portage, mode 664). But when I run eix as root, eix can create /var/cache/eix itself! It doesn't need the tmpfiles entry in the scenario that works. Maybe a setgid bit could make sense of things, but the simplest solution is probably best: a per-user cache. Regardless of the particulars of eix, I'm a lot skeptical of treating directories under /var/cache as temporary in the first place. It leads to problems just like this one, where a non-root process can't be sure that its cache directory will exist and have the correct permissions. In this case we've solved the problem by requiring either OpenRC or systemd, but that's not a good answer. We would be much better off if the ebuild could create that directory with the correct permissions once, and know that it will persist. The FHS is ambiguous here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html It calls out files specifically, Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. The fact that we can't track the directory /var/cache/eix without a file at /var/cache/eix/.keep is something else to worry about, but that's a problem we've caused ourselves and one worth ignoring if it saves us enough trouble.
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On 4/26/19 7:07 AM, Michael Orlitzky wrote: > Thus it should have its own RDEPEND on virtual/tmpfiles, making the > one in the eclass redundant. Correction, it should RDEPEND on either systemd or OpenRC. Having the "tmpfiles" binary installed is not enough; it needs to be run every reboot. The RDEPEND in the eclass is still redundant, though.
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On 4/26/19 12:53 AM, Michał Górny wrote: >> >> And the only reason we would need a transient directory created and/or >> cleaned-up is because one of those service managers is going to start a >> program that needs it. Two of them can use the tmpfiles mechanism, but >> the others must handle it on their own: in particular, they don't need >> tmpfiles_process() to do anything. >> > > No. tmpfiles is also used for programs started directly by user, such > as eix. > Good example. Does eix work on a machine running something other than systemd or OpenRC? I don't think so -- not if it needs that tmpfiles entry to be processed every reboot. Thus it should have its own RDEPEND on virtual/tmpfiles, making the one in the eclass redundant. I suspect the same is true of any other example. Let's get to the point: is there a single example of a package that works with runit, sysvinit, or daemontools but which needs tmpfiles_process() to run?
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/26/19 12:52 AM, Rich Freeman wrote: > gpg is the same. Yes, the concepts are great once you understand them > (though the smartcard standard is needlessly limited). The actual > command line interface is just painful to use if you're doing more > than just encrypting/signing something. If you want to use something > other than your default key you pass --default-key, which seems odd, > since you don't really want to change your default, and there isn't > any way to pass a "non-default" key. I get having a default key > option in a config file, since that is what it describes. And then > there is all the interactivity, which makes sense to have as an > option, but not without a command line override. I mean, the FTP > interactive console also makes sense but there is a reason everybody > uses curl/wget/etc, and not FTP+expect. default-key is exactly for config file, for other operations you use -u/--local-user -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
