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
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 1:02 AM, Jeremy Lainé 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
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
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
