Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
> >On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:
> >>>Please see #266762 for any discussion on this.
> >>Can you explain why a Policy violation (i.e. not providing shared
> >>libs for a -dev package) is of "Severity: wishlist"
> >
> >Again, see #266762.
> >
> >>esp. in the context of repeated FTBFS caused by it?
On Thu, Aug 19, 2004 at 11:58:40PM +0200, Steinar H. Gunderson 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.
On Fri, Aug 20, 2004 at 10:40:52AM +1000, Anibal Monsalve Salazar wrote:
> 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.
We have here a case of a package [rpvm] which doesn't fullfill its design
intent on non-i386 packages and someone who isn't even the package
maintainer trying to downgrade the severity to a wishlist bug. I see
no valid reasons -- technical or otherwise -- for this status change.
It's appropriate for 266762 to be wishlist, but that has no bearing
on 266837.
> Could the ctte decide whether or not this is right?
It will take the ctte some time to hold a vote, but Dirk is the package
maintainer -- he has every right to put the priority on 266837 back
to serious. Furthermore, since he didn't delegate his authority to the
committee, we'd have to have an incredibly good technical reason to ask
him to do anything else.
That said, this is an rpvm problem, not a pvm problem.
That said, I've not looked closely at the designs of either rpvm or pvm.
It might very well be that the design of pvm could sensibly incorporate
a shared lib -dev.
But I agree with Steinar that this is a bit late to make architectural
changes on a package slated for inclusion in Sarge.
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.
Maybe someone else in the committee can come up with some better ideas
than mine.
Thanks,
--
Raul
Reply to: