[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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  <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: