Raul Miller wrote: >>> To be honest, it is not pvm's problem that rpvm does not work with >>> pure upstream pvm on non-i386. > I agree. > > That said, if someone were to submit a patch for pvm which fit within > its design, and which made rpvm easier to get working, I think pvm should > accept that patch.
The only way I can imagine such a patch would be something that made pvm build a shared libgpvm3 (or a static one with -fPIC), and then we're unfortunately back where we started. >> A serious bug, #266837, has been downgraded to whislist. > That seems to me to be inappropriate. Dirk Eddelbuettel is the package > maintainer for rpvm, and Steinar H. Gunderson (the maintainer of pvm) > downgraded its priority. I think you've missed a point here (all times converted to UTC): 2004-08-19 11:38: #266837 gets filed as a serious bug against rpvm. 2004-08-19 21:26: Dirk reassigns #266837 to pvm. 2004-08-19 21:30: I set #266837 to wishlist, to merge it with #266762. As #266837 was assigned to pvm at that point, I cannot see how I would be tampering in someone else's packages. > It's appropriate for 266762 to be wishlist, but that has no bearing > on 266837. The entire discussion here is whether #266762 is wishlist or not. I claim it is; the rpvm people claim it is serious. > I know this leaves rpvm in an awkward state. I'd suggest [for sarge] > making it build statically against pvm (maybe with strict requirements on > the associated installed version of pvm), and incorporating all the bulk > that implies. Yes, this places a disproportionate storage requirement > on rpvm, but this close to release I think stupid simple changes are > better than more elegant but riskier changes. The problem is, this is not possible: rpvm _must_ be a shared library (as far as I've understood, anyhow) to work, and a shared library _cannot_ link against a static library (well, a non-PIC-compiled one, anyway) on non-i386/arm. /* Steinar */ -- Homepage: http://www.sesse.net/
