Re: Why packages in testing/unstable require the newer shared libraries ?
On Wed, 26 Nov 2008 13:53:01 -0500
Boris Toloknov <tlknv@yandex.ru> wrote:
> Hi All,
> I have debian stable (etch). Sometimes I want to install the newest
> versions of some packages from testing/unstable. Typically I can only
> install some package with the newer version of the shared libraries it
> depends on. For example dash (0.5.3-7) from etch depends on libc6
> <http://packages.debian.org/etch/libc6> (>= 2.3.5-1) while dash
> (0.5.4-12) from lenny depends on libc6
> <http://packages.debian.org/lenny/libc6> (>= 2.7-1) and debian stable
> has libc6 (2.3.6.ds1-13etch7) .
>
> Will my system be broken after upgrading libc6* along with locales,
> tzdata and binutils from testing(lenny) repository ? If not then it
> means that other programs ( for example bash ) are able to work with
> libc6 <http://packages.debian.org/lenny/libc6> (2.7-*) instead of libc6
> <http://packages.debian.org/etch/libc6> (2.3.[56]*). On other hand I
> don't think that dash (0.5.4-12) from lenny requires something that is
> absent in libc6 <http://packages.debian.org/etch/libc6> (2.3.[56]*). Why
> in that case dash and most/all of the program packages from testing
> require the newer libraries from testing instead of stable ?
>
If the dependencies are set corretly for the packages, upgrading the library
should also force you to upgrade all packages that won't work with the newer
one.
A program compiled with the newer library (usually) can't work with the older
ones due to interface (possibly on binary) changes. That depends on how much
the library changed. Sometimes they also use newer features of the library.
Programs from newer systems are usually compiled with newer libraries because
you want to the system the system to work as a whole and the new systems want
the newer libraries because other packages or the users use their features.
Some libraries can coexist at different versions, some don't and you don't want
to keep 15 versions on the same library on the system just because some
packages don't want the newer features.
As a bottom line, if you can't cope with backports and you need the newer
versions of the packages then you need to either backport yourself or use a
newer system (either testing or unstable, which unlike the name suggests is
rather stable). Stable is targeted as a server grade distribution, testing and
unstable are more targeted for the desktop (although some with contradict me on
this of course)
> Typically I want to upgrade just some package like gcompris from
> testing. What options do I have ?
> 1) Upgrade the package along with a huge set of libraries it depends on.
> But I don't want to make all my system testing/unstable.
> 2) I can get the source of the newest gcompris, lib*-dev packages,
> compile it and remove the source and lib*-dev. But it takes a lot of
> time. Moreover I can do it but my wife can't and she doesn't understand
> why it takes that much time to just install a newer version of some program.
> 3) Wait for a couple of years for the next stable release of debian.
> It's too long.
>
> I read
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html,
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html and some
> other articles however I don't understand: Why packages in
> testing/unstable require the newer shared libraries ?
>
> Thanks,
> Boris
>
Reply to: