Le Mon, Aug 31, 2009 at 01:23:39AM +0100, Stephen Gran a écrit : > This one time, at band camp, Charles Plessy said: > > Le Sat, Aug 29, 2009 at 08:06:09PM -0700, Steve Langasek a écrit : > > > On Sun, Aug 30, 2009 at 11:56:58AM +0900, Charles Plessy wrote: > > > > as per Policy § 10.2, I would like to know if everybody agrees if I > > > > change the > > > > libbam-dev package to compile libbam.a with -fPIC. > > > > > What are the reasons for not shipping a shared library? That's always > > > preferred over use of -fPIC for static libs, so we should examine the > > > reasons for this first. > > > > I forgot to mention that the upstream sources do not build a shared library. > > Is there some reason you as a maintainer can't? If the library has no > API or ABI stability, that might be a good reason not to (although it's > a better reason to talk to upstream about why they have to do so), but > otherwise, why not just do it?
I started to write a message about to ask upstream why they do not make a shared version of libbam, but I am blocked because I could not give good reason of why Debian can not make -fPIC version of libbam. To my knowledge, libbam is used by the samtools themselves, as well as the Bio::SamTools perl library. For Bio::SamTools, -fPIC is definitely not a problem because the upstream README mentions to use this option if necessary. For the samtools program, it will be easy to prepare a version that is built against a non-fPIC libbam.a, but I fail to understand why it is important since if upstream releases a shared version of libbam, it will have to be compiled with -fPIC anyway, which makes little difference between the situation we want to avoid and the situation we want to recommend. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
