Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
* Brian May (bam@snoopy.apana.org.au) wrote:
> On Mon, 2002-05-06 at 14:09, Stephen Zander wrote:
> > >>>>> "Junichi" == Junichi Uekawa <dancer@netfort.gr.jp> writes:
> > Junichi> They don't upgrade properly.
> >
> > "You keep using that word. I do not think it means what you think it
> > means."
>
> Definitions:
> * 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
> problems.
>
> The initial problem is that the old library conflicts with the new
> library.
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
simultaneously.
> When the user does install the new library and the new packages, it will
> remove the old library.
Exercise:
$ 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
--
Joshua Haberman <joshua@haberman.com>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: