[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#264403: rpvm: FTBFS m68k: /usr/lib/pvm3/conf/LINUXR68R.def: No such file or directory



On Wed, Aug 18, 2004 at 10:02:21AM -0500, Dirk Eddelbuettel wrote:
>> - rpvm should NOT check for a static library if it cannot use a static
>>   library. This is a bug in rpvm upstream.
> Nope: rpvm can only assume static libs, as the rest of the world uses only
> static libs.  We are different, and can be different as __the combination of
> -Lpath/to/libfoo -lfoo inferred from static libs works for shared libs too__ 
> provided there are working shared libs.

But you cannot assume static libs imply working shared libs, which you
obviously seem to do. You say "we can be different from upstream because
X, but X is false, so your package is what breaks my package since X is
false". Sorry, but that does not make sense. :-)

> Pvm is broken for sarge AFAICT. I'd expect your mix of shared and static to
> break with way more packages that just rpvm (which happens to rely on
> dyn.lib. loading to extend the functionality of GNU R at run-time).

(Note that this is not _my_ mix of shared and static libs; this is for
historical reasons from the previous maintainer. :-) )

Shared and static library mix should not pose a problem for _any_
well-behaved package (the availability of the libraries should be checked
separately for different libraries _and_ for shared/static libraries as long
as it actually matters which one to use), and as you can see, the pvm package
has been working for ages without any problems caused by this. Moreover, the
problem in question is not from the mix at all; it is simply because rpvm's
configure script is broken, assuming that it can create a shared library
linking against libpvm3 and libgpvm3 just because libpvm3.a and libgpvm3.a
exist.  (The fact that pvm probably breaks policy by not providing a shared
library is really a different issue, and that is why I'm pulling in the
debian-release; see below.)

> I don't see what wasting precious RM time gains us here, other than getting
> PVM completely blown out of sarge unless fixed.

I want to

a) verify that "libgpvm3 does not have a shared library" is indeed an RC bug.
b) get that bug tagged sarge-ignore, as I see a stable pvm package in sarge
   as a lot more important than getting rpvm working on m68k/amd64.

/* Steinar */
-- 
Homepage: http://www.sesse.net/



Reply to: