With the update of p11-kit to version 0.23.4-1, it is no longer possible to install both the 32 and 64 bit versions. Attempts to do so result in: Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/lib/systemd/user/p11-kit-remote@.service conflicts between attempted installs of p11-kit-0.23.4-1.fc26.i686 and p11-kit-0.23.4-1.fc26.x86_64
Hmm looks like a new build showed up on koji to fix this issue while I was filing. This should be fixed by version p11-kit-0.23.4-3
Yes, it should be fixed with p11-kit-0.23.4-3.fc26, though the fix is not perfect. The problem was that the systemd unit file contained two arch-dependent strings ("lib64" or "lib") like this: ExecStart=/usr/lib64/p11-kit/p11-kit-remote /usr/lib64/p11-kit-proxy.so For the first occurrence of "lib64", this location was actually wrong and it should be /usr/libexec: https://github.com/p11-glue/p11-kit/pull/57 For the latter, however, we need to figure out how to specify a PKCS#11 module in an arch-independent way. So far, we moved the file to p11-kit-tools subpackage. That is a temporary solution, as p11-kit-tools now have the same multilib problem.
(In reply to Daiki Ueno from comment #2) > Yes, it should be fixed with p11-kit-0.23.4-3.fc26, though the fix is not > perfect. > > The problem was that the systemd unit file contained two arch-dependent > strings ("lib64" or "lib") like this: > > ExecStart=/usr/lib64/p11-kit/p11-kit-remote /usr/lib64/p11-kit-proxy.so > > For the first occurrence of "lib64", this location was actually wrong and it > should be /usr/libexec: > https://github.com/p11-glue/p11-kit/pull/57 > > For the latter, however, we need to figure out how to specify a PKCS#11 > module in an arch-independent way. > > So far, we moved the file to p11-kit-tools subpackage. That is a temporary > solution, as p11-kit-tools now have the same multilib problem. But that is at least better because if i have the issue there I can probably just remove p11-kit-tools.i686.
If the p11-kit-tools does not contain any shared libraries or header files it is not a multilib package and so the conflict between 32-bit and 64-bit build of it does not matter. Basically there will be only the 64-bit variant of it in the 64-bit OS.
Kai Engert knows more about the reasoning of why the two should be parallel installable.
Well, every subpackage that contains a shared library and the corresponding -devel subpackage is by default multilib -> should be parallel installable. I am not sure whether (and how) you can opt out of it.
(In reply to Tomas Mraz from comment #6) > Well, every subpackage that contains a shared library and the corresponding > -devel subpackage is by default multilib -> should be parallel installable. > I am not sure whether (and how) you can opt out of it. I think what Tomas was trying to say, is that there is no reason to ever install the 32-bit version of p11-kit-tools package under a 64-bit os. Therefore, although trying to install both presents a conflict, you really should not be doing that in the first place.
Exactly and moreover the 32bit p11-kit-tools subpackage will not even be present in the 64bit repositories.
Just some general thought: The package name "tools" sounds like a package that contains command line utilities, and "rpm -qi" for your package also mentions "contains command line tools". But it it seems it doesn't contain any command line tools, but rather some remote service files. Maybe the package name isn't ideal.
(In reply to Stef Walter from comment #5) > Kai Engert knows more about the reasoning of why the two should be parallel > installable. It's important that the p11-kit-trust.so modules of multiple arches can be installed in parallel. From the perspective of the ca-certificates package, it's required that the "/usr/bin/p11-kit extract" command is available, but one arch is sufficient for that.
Given that this runs a server which increases the system's attack surface, one question a level higher, is whether this server should be run by p11-kit package at all. Is that server needed for all users of p11-kit? Does it need to run as root?
Thank you all for the insights. For the record, I removed the systemd files in upstream and renamed the subpackage from -tools to -server, as it now contains only the server and client components.