On 02/17/2014 05:07 PM, Justin Clift wrote:
Hi Kaleb,
Just noticed a small weirdness with the GlusterFS rpms generated from
from git master head.
In glusterfs-api rpm:
* /usr/lib64/libgfapi.so.6
* /usr/lib64/libgfapi.so.6.0.0
In glusterfs-api-devel rpm:
* /usr/lib64/libgfapi.so
They should all be in the glusterfs-api rpm shouldn't they?
Nope. This is ELF sharedlib juju.
At compile time the linker looks for libfoo.so. It reads the SO_NAME,
which is libfoo.so.x (or libfoo.so.x.y.z), from libfoo.so (which is just
a symlink to libfoo.so.x); Later, at run-time, the dyld loads libfoo.so.x.
RPM's packaging rules say that libfoo.so.x (and libfoo.so.x.y.z) belong
in the foo.rpm, but the libfoo.so symlink belongs in the foo-devel.rpm.
IOW a run-time only install only needs libfoo.so.x or libfoo.so.x.y.z.
A developer who wants to link with the lib needs the -devel rpm with
libfoo.so.
The purist packagers like this because it keeps the file system from
being filled with lib*.so symlinks that aren't needed except by developers.
Debian/Ubuntu-style dpkg has similar rules for their -dev dpkgs.
If so, I can include the fix in my Glupy rename patch, as it's
already moving a few things around for the API rpms.
Regards and best wishes,
Justin Clift
--
Open Source and Standards @ Red Hat
twitter.com/realjustinclift
--
Kaleb
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
