[Resending this to [EMAIL PROTECTED], as I was not subscribed at the time and thus the mail bounced]
reassign 266762 tech-ctte thanks On Fri, Aug 20, 2004 at 10:40:52AM +1000, Anibal Monsalve Salazar wrote: > Invoking the ctte, as per sgunderson's suggestion. In another message > edd didn't oppose to bring this matter to the ctte. I think, the three > parties involved agree to request the ctte's opinion to this problem. Trying to follow the procedure of http://www.debian.org/devel/tech-ctte here, reassigning #266762 to the ctte. The discussion spans over multiple bugs, but here is my current understanding of the dispute I've summarized into #266762 (which #266837 is merged into): - pvm does, for historical reasons, provide a shared libpvm3 but no libgpvm3. (libpvm3 is the shared library used for almost all PVM programs, libgpvm3 is a library supplementing libpvm3 with a few extra functions.) pvm upstream does only supply static libraries, and the shared libpvm3 is a Debian-specific extension; I guess the previous maintainer (I took over maintainership for pvm some time ago) simply forgot libgpvm3. - rpvm, an extension for integrating GNU R with PVM, gets FTBFS bugs with current pvm in Debian, as it tries to do "gcc -shared -o rpvm.so <object files> -lpvm3 -lgpvm3", and -lgpvm3 resolves to libgpvm3.a, which fails on all platforms except i386 and arm (since libgpvm3.a is not built with -fPIC). rpvm's configure script never checks for the presence of shared libpvm3.so or libgpvm3.so files; first it tries to link to -lpvm3 and if that fails, it does "test -f /usr/local/lib/libpvm3.a" and then optionally a third place (PVM's library directory). - Dirk Eddelbuettel claims that pvm is violating policy (section 8.3, I presume) by not providing a shared library for libgpvm3. Furthermore, he claims that the pvm package is broken for "mixing" shared and static libraries (ie. providing both shared and static libraries for libpvm3, but only static for libgpvm3). This is bug #266762. - I claim that pvm is not violating policy section 8.3, as PVM's libraries are explicitly not intended for anything but static linking from upstream (section 8.3, third exception); this is simply for performance reasons. Anybody doing high-performance computing in a cluster would link statically to get lower call overhead, which is (AFAIK) the reason why PVM upstream only builds static libraries. Furthermore, I claim that the "mix" of static and shared libraries does not pose a problem at all; se my build log on hppa with all-static libraries in bug #266837. - I intend to make a shared libgpvm3 part of the pvm package, but as this requires hacking into PVM's build process (which I am not intimately familiar with) I do not intend to do this and potentially destabilize pvm right before the sarge release. - It should also be noted that there _was_ a bug in PVM that was at fault for some rpvm build failures (an unescaped call to "tr" in a shell script). This is bug #264403, but several of our arguments have been Cc-ed to that bug as well. This was fixed in pvm 3.4.2-12. I claim this is completely unrelated to the bug we're discussing here -- Dirk has claimed otherwise in the past, but I'm unsure of his current position on this. In short, the question is: Must the pvm package provide a shared libgpvm3 or not? If it does not, I intend to keep the pvm package as it is (except for the "build for i386 on amd64 kernel" bug, which I will fix shortly, and which is again a separate issue) for sarge. > A serious bug, #266837, has been downgraded to whislist. For the record, #266762 (which is the one I'm reassigning to debian-ctte) is merged with #266837; it's the same dispute. /* Steinar */ -- Homepage: http://www.sesse.net/