Le Sun, Sep 05, 2010 at 01:55:59PM +0200, Julien Cristau a écrit : > > > Why does any of this prevent the existence of a libeplplot3 binary > package? For most libraries, we're not shipping more than one version > at a time in each suite, but their packaging has to follow policy > regardless. One of the concerns is to make upgrades work, and that > applies to emboss just like to every other package in Debian.
Here, upgrading means replacing all old EMBOSS and EMBASSY programs by the new ones. Nothing else is supported upstream. I do not think that splitting emboss-lib in libeplplot3 and libeplplot-dev has a particular concrete benefit other than making the package compliant with a Policy chapter that should not apply to it. Policy section §8's second paragraph defines the scope of the chapter: ‘This section deals only with public shared libraries: shared libraries that are placed in directories searched by the dynamic linker by default or which are intended to be linked against normally and possibly used by other, independent packages.’ I would prefer taking a direction that makes the eplplot library private. I will study how to move emboss-lib's files to /usr/lib/emboss or /usr/share/emboss. Patches going in this direction would be very welcome. -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
