[Gluster-devel] glusterfs 3.4.0 vs 3.4.1 potential packaging problem?

[Anand Avati]

>
> [2013-10-08 17:33:36.662549] I [glusterfsd.c:1910:main]
> 0-/usr/sbin/glusterd: Started running /usr/sbin/glusterd version 3.4.1
> (/usr/sbin/glusterd --debug)
>

...


> [2013-10-08 17:33:36.664191] W [xlator.c:185:xlator_dynload] 0-xlator:
> /usr/lib64/glusterfs/3.4.0/xlator/mgmt/glusterd.so: cannot open shared
> object file: No such file or directory



I think the issue can be summarized with the above two log lines. glusterd
binary is version 3.4.1 (PACKAGE_VERSION of glusterfsd is "3.4.1") but
libglusterfs is trying to open ".../3.4.0/...glusterd.so" (i.e
PACKAGE_VERSION during build of libglusterfs.so is "3.4.0").

The reality in code today is that glusterfsd and libglusterfs must be built
from the same version of the source tree (for reasons like above), and this
needs to be captured in the packaging.

I see that the glusterfs.spec.in in glusterfs.git has:

Requires:         %{name}-libs = %{version}-%{release}

for the glusterfs-server RPM. That should have forced your glusterfs-libs
to be updated to 3.4.1 as well.

Kaleb,
Can you confirm that the Fedora RPMs also have this "internal dependency"
between packages? If it already does, I'm not sure how Jeff ended up with:

glusterfs-libs-3.4.0-8.fc19.x86_64
glusterfs-3.4.1-1.fc19.x86_64

without doing a --force and/or --nodeps install.

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20131008/bdb76a17/attachment-0001.html>