Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
* Brian May (email@example.com) wrote:
> On Mon, 2002-05-06 at 14:09, Stephen Zander wrote:
> > >>>>> "Junichi" == Junichi Uekawa <firstname.lastname@example.org> writes:
> > Junichi> They don't upgrade properly.
> > "You keep using that word. I do not think it means what you think it
> > means."
> * By library upgrade I mean major library upgrade, one which
> changes the major number of the library rendering making it
> incompatible with current applications.
> I think this is an important issue, and I in my quick scan I haven't
> seen an email that really addresses this, so I will bite.
> Having multiple major versions of a shared library causes lots of
> The initial problem is that the old library conflicts with the new
A new shared library package should *not* conflict with the old library
package, for exactly the reasons you describe. Shared libraries are
specifically designed to allow multiple soversions to be installed
> When the user does install the new library and the new packages, it will
> remove the old library.
$ apt-get install liborbit0 liborbit2
Notice the lack of conflict (liborbit is just the first library I could
find with two sonumbers in the archive)
I am becoming increasingly convinced that library packaging in Debian is
somewhat ad hoc. As someone who is taking on a library package that soon
is making backward-incompatible API changes and bumping the sonumber, I
am interested in establishing (or discovering) a "best practice" method
for this sort of transition.
Joshua Haberman <email@example.com>
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com