Package maintainers bumping depends versions

[shadowking]

1) I noticed several times: package X needs gtk 2.16 but 2.12 is to be installed...

This is wrong. Many times the package DOESN'T need a high library and will build fine, but the maintainer bumps the version on the binary package. This is really annoying as i should be able to simply install a testing package into stable without getting bugged with errors. WHY ???


2) The other thing is lots of *optional* depends are like mandatory according to the maintainer. WINE doesn't need all that fluff for example. Again makes it harder to install & bloats your system

[smallchange]

So use a different system. The way you complain about having to know something to use Debian I doubt you will ever be happy with it.

[stevepusser]

Hmmm...have you backported any of those packages to Lenny and got a good build? I have done quite a few for the Mepislovers repo, and found that they don't lie. If you don't have the correct gtk version, you will get a build failure. During the packaging procedure, there's a step called shlib that goes through all the built libraries, extracts the symbols, and compares them to a internal database to determine what's the minimum version to depend on. I found this out after backporting the latest libphoto to work with a new Digikam, but Digikam would only depend on an older version, since that fullfilled all the symbol requirement.

Anyway, you can install a libgtk2.0-0 2.18 from lenny-backports to solve that problem, too.

[shadowking]

@stevepusser : Thanks for the reply. You are the mepis CR repo packager ?

I've built many packages fine. Sometimes you don't need or to build it (you have the correct libs) but the binary package specify higher version number, While the build deps list the correct one.

[saulgoode]

I would surmise that the dependencies relevant to 1) are pretty much dictated upstream. I can't imagine a package maintainer would bump a dependency version of his own accord. Do you have a specific example?

[shadowking]

I would surmise that the dependencies relevant to 1) are pretty much dictated upstream. I can't imagine a package maintainer would bump a dependency version of his own accord. Do you have a specific example?

I've seen a few. One that springs to mind is Gparted:

http://packages.debian.org/squeeze/gparted

It doesn't need gtk 2.14 and builds on 2.12

Smplayer doesn't need Qt 4.5 and builds on 4.3:

http://packages.debian.org/sid/smplayer

The following packages are BROKEN:
smplayer
The following packages will be REMOVED:
libboost-serialization1.35.0{u} libneon27{u} libsensors3{u} libsnmp-base{u} libsnmp15{u}
1 packages upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
Need to get 1286kB of archives. After unpacking 9314kB will be freed.
The following packages have unmet dependencies:
smplayer: Depends: libqt4-network (>= 4:4.5.3) but 4.4.3-1+lenny1 is installed.
Depends: libqt4-xml (>= 4:4.5.3) but 4.4.3-1+lenny1 is installed.
Depends: libqtcore4 (>= 4:4.5.3) but 4.4.3-1+lenny1 is installed.
Depends: libqtgui4 (>= 4:4.5.3) but 4.4.3-1+lenny1 is installed.


The builds page is different:

http://packages.debian.org/source/sid/smplayer

libqt4-dev (>= 4.3)
Qt 4 development files

[smallchange]

A program may be able to build with a library version, say 4.3, while the same program built against the 4.5 version of the library will not run with version 4.3.

[shadowking]

This would be correct when you have a abi change say v3 to v4. But 4.3 > 4.5 ?

You sure it applies to Qt ?

[craigevil]

Packages from Testing are not meant to be installed on stable, that's why backports exists. If you just have to have a package from testing then you back port it yourself, although a lot of the time the version in backports is a higher version than in testing.

Packages move from unstable into testing, 99% of the time the depends are the same for unstable and testing. smplayer for example in testing is built for kde4 while stable only has kde3.

Code: Select all

 $ apt-cache show gparted
Package: gparted
Priority: optional
Section: gnome
Installed-Size: 4156
Maintainer: Anibal Monsalve Salazar <anibal@debian.org>
Architecture: i386
Version: 0.5.1-1
Depends: libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libglibmm-2.4-1c2a (>= 2.22.0), libgtk2.0-0 (>= 2.14.0), libgtkmm-2.4-1c2a (>= 1:2.18.0), libpangomm-1.4-1 (>= 2.26.0), libparted1.8-12 (>= 1.8.8.git.2009.06.03-1), libsigc++-2.0-0c2a (>= 2.0.2), libstdc++6 (>= 4.4.0)
Recommends: gksu
Suggests: xfsprogs, reiserfsprogs, reiser4progs, jfsutils, ntfsprogs, dosfstools, yelp, kpartx, dmraid, dmsetup
Filename: pool/main/g/gparted/gparted_0.5.1-1_i386.deb
Size: 1382540
MD5sum: 6d902650489c158789363c81bb2883d8
SHA1: 52e401eb96c43650916c1b76d263f427996def09
SHA256: 383f7ccc75c9cf47ced633ba56087b2a2d9e9bdf6f8c699e32bf81da1bcd815d
Description: GNOME partition editor
 GParted uses libparted to detect and manipulate devices and partition
 tables while several (optional) filesystem tools provide support for
 filesystems not included in libparted.
Homepage: http://gparted.sourceforge.net
Tag: admin::filesystem, role::program, scope::utility, suite::gnome, uitoolkit::gtk

craig@craigevil:~$ apt-cache show smplayer
Package: smplayer
Priority: optional
Section: video
Installed-Size: 2988
Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Architecture: i386
Version: 0.6.8-2
Depends: libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), libqt4-network (>= 4:4.5.3), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.5.3), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.1.4), mplayer-nogui | mplayer
Recommends: smplayer-translations, smplayer-themes
Filename: pool/main/s/smplayer/smplayer_0.6.8-2_i386.deb
Size: 1285620
MD5sum: b47951c65d7e2a7e93720804bdfeb4a4
SHA1: 3797f9e2a1615ea14a41bd95f0eaff25a5d5c6d6
SHA256: a6bfb88d8885fb712e965b6b325dcc2c051f09519bd343554f6aa7440869fc71
Description: complete front-end for MPlayer
 Qt Mplayer front-end, with basic features like playing
 videos, DVDs, and VCDs to more advanced features like support
 for MPlayer filters and more. One of the most interesting features
 of SMPlayer: it remembers the settings of all files you play.
 So you start to watch a movie but you have to leave... don't
 worry, when you open that movie again it will resume at the same
 point you left it, and with the same settings: audio track,
 subtitles, volume...
Homepage: http://smplayer.sourceforge.net/
Tag: interface::x11, role::program, uitoolkit::qt, use::playing, works-with::audio, x11::application

[BioTube]

A binary built against a later version of a library cannot be used against an earlier version. That's just the way it is.

[shadowking]

A binary built against a later version of a library cannot be used against an earlier version. That's just the way it is.

Is this strictly speaking ? You are saying there is zero backwards compatibility - that is really bad. Why does Geany from testing install fine on lenny ? If the maintainers build is testing then it won't run on lenny right ? But it does...

http://packages.debian.org/squeeze/geany

There must still be some backwards compatibility from lenny to testing as some apps / utils work without recompiling. GCC , libc even gtk+ are still stable between lenny ~ squeeze ?

[saulgoode]

This would be correct when you have a abi change say v3 to v4. But 4.3 > 4.5 ?

Typically (recommend practice is that) changes in major version numbers occur when formats of data files, plug-ins, or scripting interfaces lead to incompatibilities. ABI (even API) changes might occur during minor version upgrades (this according to the GNU project's recommendations for major.minor.release-build versioning conventions).

A binary built against a later version of a library cannot be used against an earlier version. That's just the way it is.

Technically, one might very well "get away" with using an earlier version of a library; though I certainly understand a developer's reluctance to support such usages.

I would surmise that the dependencies relevant to 1) are pretty much dictated upstream. I can't imagine a package maintainer would bump a dependency version of his own accord. Do you have a specific example?

I've seen a few. One that springs to mind is Gparted:

http://packages.debian.org/squeeze/gparted

It doesn't need gtk 2.14 and builds on 2.12

On the surface, your example seems very cogent. I also get frustrated when development versions bump dependencies (it indeed makes it harder to participate in the development). That being said, I tend to lend the developers the benefit of the doubt with regard to testing/dev branches. Such software is not merely being designed to work at this point in time, but is targeted toward a release date sometime in the future and the developers seek to coordinate (and have tested) their project with the expected versions of dependencies at the time of release (perhaps some other project is dictating that Squeeze will require 2.14).

For example, the gparted developer may be fully aware that by the time Squeeze reaches Stable, the shipped GTK library will be at 2.14 and thus wishes to have some integration testing performed as soon as possible.

[plugwash]

1) I noticed several times: package X needs gtk 2.16 but 2.12 is to be installed...

This is wrong. Many times the package DOESN'T need a high library and will build fine, but the maintainer bumps the version on the binary package. This is really annoying as i should be able to simply install a testing package into stable without getting bugged with errors. WHY ???

First some basics on versions of libraries. The rule is that new versions that come without a soname change (usually new minor versions but not everything follows this convention) may add stuff to the ABI but not remove stuff or change the behaviour of existing stuff. Versions that come with a soname change (usually new major versions) may change pretty much anything.

Now due to symbol versioning and macros in headers it is possible (but not a certainty) for a binary to depend on new parts of the ABI even if the source did not depend on new parts of the API. In general dependencies that are too loose are MUCH worse than dependencies that are tighter than necessary.

So debian automatically generate the dependencies on binary packages and there are a couple of methods for doing this (the method used is chosen by the library package). The old system (which is still widely used because it's simpler) simply takes a single version number from the libraries dev package (this version may be lower than the version of the dev package). The new system involves looking at what symbols the binary actualy uses and then looks at lists of when those symbols were introduced to calculate a version number.

2) The other thing is lots of *optional* depends are like mandatory according to the maintainer. WINE doesn't need all that fluff for example. Again makes it harder to install & bloats your system

The "wine" package in debian is a metapackage meant to bring in a complete wine setup. If you want to experiment with which bits of wine (and their associated dependencies) you need yourself you can do so

[stevepusser]

@stevepusser : Thanks for the reply. You are the mepis CR repo packager ?

I've built many packages fine. Sometimes you don't need or to build it (you have the correct libs) but the binary package specify higher version number, While the build deps list the correct one.

Sorry I did not get back sooner, but yes, I have the most packages in the Mepis CR, I'm Stevo on the ML forums...but most of that is just rebuilding upstream Debian packages. The hard work is already done.

I have noticed that for SMPlayer myself. I like to build it often from svn pulls, which is very easy since the developer includes a deb building script with the source. SMPlayer built on qt4.4 will work on qt4.5 also, but not the other around. I'm sure the reason is because it automatically uses features (ABI) in the newer 4.5 when available.