Bug#587287: mkfs.ocfs2 depends on libdlm-dev

2010-06-28 Thread Joel Becker
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

2010-06-28 Thread Joel Becker
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

2010-06-28 Thread Patrick J. LoPresti
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

2010-06-28 Thread Jeremy Lainé

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

2010-06-26 Thread Patrick J. LoPresti
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