Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
* Brian May (firstname.lastname@example.org) wrote:
> On Mon, 2002-05-06 at 14:09, Stephen Zander wrote:
> > >>>>> "Junichi" == Junichi Uekawa <email@example.com> 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 <firstname.lastname@example.org>
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org