On Wed, 2019-08-07 at 18:59 -0400, Alexander Bauer wrote:
> Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel)
> Requires: liburcu-cds.so.1()(64bit)
> Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel)
> liburcu-cds.so.1()(64bit)
> Updated By: userspace-rcu-0.10.0-3.el7.x86_64 (centos-nfs-ganesha28)
> ~liburcu-cds.so.6()(64bit)
> Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel)
> Requires: liburcu-bp.so.1()(64bit)
> Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel)
> liburcu-bp.so.1()(64bit)
> Updated By: userspace-rcu-0.10.0-3.el7.x86_64 (centos-nfs-ganesha28)
> ~liburcu-bp.so.6()(64bit)
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest
Why is centos-nfs-ganesha28 repo providing its own userspace-rcu
package? It seems like it ought to be picking that up from EPEL as
well.
CentOS Storage SIG packages aren't built with EPEL packages, nor can they be. At least not at present AIUI. Thus I would claim, generally, that you should not mix CentOS SIG and EPEL on the same machine.
I believe there are plans afoot to more tightly integrate CentOS, EPEL, and Fedora, such that SIG packages would be able to use EPEL, but those haven't come to fruition yet, AFAIK. Maybe we will get a status update at the upcoming CentOS dojo in Boston in a couple of weeks.
I don't remember the timing of ganesha using userspace-rcu, but even Gluster has been shipping its own userspace-rcu. The ganesha-2.7 builds under gluster in the Storage SIG would have used it, if it was even using it all at.
If there is a need for it then it should probably provide lttng packages
as well, as they typically require a certain version of urcu.
Centos, or more accurately, the Ceph builds in the Storage SIG, provide the lttng-ust packages that were (apparently) used to build ganesha. I say apparently because I don't see where else they could have come from. Looks like I need to tag those into the ganesha-28 repos.
--
Kaleb