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

Re: BIND 9.X, shared libraries, and package pools



>>>>> "Josip" == Josip Rodin <joy@cibalia.gkvk.hr> writes:

    Josip> Oh, of course. (Packages including several shared libraries
    Josip> suck as far as our naming scheme is concerned :o)

Does bind come with multiple libraries? If so, I think they should
really be split up, according to standard convention. (unless there
really are too many libraries to split up).

This is because it breaks more then just the naming system.

It is also impossible to get depends right too (on packages that
depend on a library).

The proper way is just to depend on lib<library><majorversion>, so
when the major version changes, the newer version of the library will
automatically be installed. However, this is not possible for packages
with multiple libraries. 

Assume for instance, a package lib-a 1.0 has two libraries (liba.1 and
libb.1) (these should be symlinks not the library). Package b 1.0 and
c 1.0 are compiled from liba.1 and libb.2. 

Package: lib-a
Version: 1.0

Package: b
Version: 1.0
Depends: lib-a (>= 1.0)

Package: c
Version: 1.0
Depends: lib-a (>= 1.0)

Version 2 of lib-a is released. No incompatibilities are introduced,
and no problems are created.

Version 3 of lib-a is now released. It contains liba.1 and libb.2
(libb is now incompatible with the old version). Package c has been
compiled to use liba.1 and libb.2, however package b has is incompatible.

Package: lib-a
Version: 3.0

Package: b
Version: 1.0
Depends: lib-a (>= 1.0)

Package: c
Version: 1.0
Depends: lib-a (>= 3.0)

It is obviously not possible to install version 1 and version 2 of
lib-a as the same time (liba.1 conflicts).  So, no matter what you do,
you will either break package b or package c.

To make matters worse, the depends is wrong. The above example says
that package b can be installed regardless of what version lib-a is,
even though it is incompatible with version 3. Version depends do not
help - it is not possible to know what future version of lib-a will
introduce incompatibilities.

This is especially bad (I think: just guessing here) now that package
pools are introduced, because the updater will happily install lib-a
(3), b, and c in testing, even though they are clearly incompatible
(because the depends is wrong, and b will become broken).


(I think this explanation really needs to written up somewhere; I
probably will put it online my website when I get time).
-- 
Brian May <bam@debian.org>



Reply to: