Bug#587287: mkfs.ocfs2 depends on libdlm-dev
It looks as though there are two issues here: a/ My understanding is that upstream does a dlopen() on libdlm_lt.so in order to be able to use libdlm_lt.so.2 or libdlm_lt.so.3 depending on the system. On Debian/squeeze or better, the package in use is libdlm3, so libo2dlm should dlopen() libdlm_lt.so.3 directly instead of libdlm_lt.so, so that we only need the libdlm3 package, not libdlm3-dev. I have added a patch for the next upload of ocfs2-tools which does just that: http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/libo2dlm-dlopen-libdlm_lt.patch b/ libdlm3 is only required when using a userspace cluster stack instead of the built-in o2cb. Therefore, having a ocfs2-tools *depend* on libdlm3 is probably wrong. I think that making ocfs2-tools-cman and ocfs2-tools-pacemaker depend on libdlm3 is probably the way to go. Any thoughts on this Joel? Jeremy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
On Mon, Jun 28, 2010 at 1:02 AM, Jeremy Lainé jeremy.la...@m4x.org wrote: It looks as though there are two issues here: a/ My understanding is that upstream does a dlopen() on libdlm_lt.so in order to be able to use libdlm_lt.so.2 or libdlm_lt.so.3 depending on the system. OK, but that will also pull in lidlm_lt.so.4, or libdlm_lt.so.5, or libdlm_lt.so.6... It would be wrong for libo2dlm to load libdlm_lt.so.4 before the developers even know what it is. The results would be unpredictable; potentially even dangerous. The whole point of libfoo.so.N is that N changes when and only when binary compatibility is broken. It also allows multiple Ns to co-exist on the same system. Using dlopen() on libfoo.so breaks both of those. libfoo.so is a development library. libfoo.so.N is a production (run-time) library. To have a production binary depend on libfoo.so is simply a bug, and I would like to help fix this bug upstream. I can think of three ways to do so: 1) Link against -ldlm_lt at compile time. This was rejected by the ocfs2 maintainers some time ago for introducing undesired dependencies. or 2) Have configure detect the version of libdlm_lt.so.N at compile time, and have libo2dlm use that. or 3) Modify libo2dlm/o2dlm.c to attempt to dlopen() libdlm_lt.so.3, then try libdlm_lt.so.2 if that fails. This is simplest, and maximizes portability of the binary, so it would be my suggestion. Joel, I volunteer to create and test a patch for any of these approaches, if you would find any of them acceptable. Just let me know. I have added a patch for the next upload of ocfs2-tools which does just that: http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/libo2dlm-dlopen-libdlm_lt.patch Thank you. Apparently, Suse is already applying exactly the same patch. But instead of every distribution fixing this bug for themselves, I would like to work together to get it fixed upstream. - Pat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
On Mon, Jun 28, 2010 at 10:02:06AM +0200, Jeremy Lainé wrote: b/ libdlm3 is only required when using a userspace cluster stack instead of the built-in o2cb. Therefore, having a ocfs2-tools *depend* on libdlm3 is probably wrong. I think that making ocfs2-tools-cman and ocfs2-tools-pacemaker depend on libdlm3 is probably the way to go. Any thoughts on this Joel? Absolutely. The dlopen() exists expressly to avoid ocfs2-tools depending on libdlm3. Joel -- Under capitalism, man exploits man. Under Communism, it's just the opposite. - John Kenneth Galbraith Joel Becker Consulting Software Developer Oracle E-mail: joel.bec...@oracle.com Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
On Mon, Jun 28, 2010 at 08:13:25AM -0700, Patrick J. LoPresti wrote: 2) Have configure detect the version of libdlm_lt.so.N at compile time, and have libo2dlm use that. or 3) Modify libo2dlm/o2dlm.c to attempt to dlopen() libdlm_lt.so.3, then try libdlm_lt.so.2 if that fails. This is simplest, and maximizes portability of the binary, so it would be my suggestion. Joel, I volunteer to create and test a patch for any of these approaches, if you would find any of them acceptable. Just let me know. SLES is already running with approach (3), and since we really rely on cluster3, this is the best thing for now, I think. Mainline already supports dlmfs on top of fs/dlm. So later releases of ocfs2-tools will not use libdlm at all. This dlopen() will eventually become backwards compatibility. Joel -- The question of whether computers can think is just like the question of whether submarines can swim. - Edsger W. Dijkstra Joel Becker Consulting Software Developer Oracle E-mail: joel.bec...@oracle.com Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587287: mkfs.ocfs2 depends on libdlm-dev
Package: ocfs2-tools Version: 1.4.4-2 While trying to run mkfs.ocfs2 (Pacemaker cluster stack), I consistently got the following error: Unable to access cluster service while initializing the dlm I tracked this down to mkfs.ocfs2 attempting to dlopen() libdlm_lt.so. Unfortunately, this symlink is part of the libdlm-dev package. Production releases should not depend on development packages. And if they do, the dependencies need to be explicit, because errors like this are painstaking to diagnose. :-) To be honest, I am not sure whether this is a bug in ocfs2-tools (which has this unmentioned dependency on libdlm-dev) or in redhat-cluster (which puts this .so link in libdlm-dev). Normally, .so links are part of development packages, but in this case, perhaps it belongs in libdlm3 (?). Let me know if you think I should submit this bug against redhat-cluster instead. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
