Why Should One Not Update Everthing from Backports?

[emariz]

While I've been using Debian for various years, I have never actually used Stable. No Stable means no Backports, and I have a doubt about the latter.

After reading Backports's documentation and the APT Preferences's manual page, I understand that, as of Squeeze, a backport must be installed manually, and that already installed backports are automatically updated. Also, because Backports archives have a pin-priority of 1, one cannot update all installed packages to the versions available in Backports.

I guess that one could achieve it by giving the Backports archive a pin-priority of 991. However, using the whole Backports repository is discouraged everywhere, and I don't really know why.
How serious are these warnings? Does it cause a dependency Hell or is it just a warning for novice users?

[dilberts_left_nut]

As far as I know, it is because there is no guaranteed upgrade path to the next stable version of whatever apps installed from backports.
A lot of effort goes into making sure upgrading to the new stable, correctly imports the settings from the previous version in oldstable. Having a backported "new" version MAY introduce unforseen issues, hence the warning.

[emariz]

I installed a minimal Squeeze system yesterday, enabled Backports and Proposed Updates and changed the priority of the Backports archive to 500, so that all Backports are automatic installable candidates. The system built without problems but I noticed my first issue while installing Network Manager:

· There is no network-manager-gnome in Backports.
· Squeeze provides network-manager-gnome 0.8.1-2, which depends, among many other packages, on network-manager >= 0.8.1.
· Squeeze provides network-manager 0.8.1-6+squeeze1 and Backports has it at version 0.8.4.0-2~bpo60+1. Thus, because both versions meet the requirement, their archives have the same priority and the backport is newer, the latter is pulled.
· network-manager 0.8.4.0-2~bpo60+1 breaks network-manager-gnome < 0.8.2, halting the installation.

Aptitude offered me to install the Squeeze version of network-manager as the first solution, and then I forbade network-manager from Backports.

I just wanted to show a case where APT encounters a non-installable situation by enabling all Backports for automatic installation. This was relatively easy to solve but there might be difficult (or impossible) situations with other packages.

[bw123]

I am going to read this thread a little better over the next day or two but right now, the main reason I haven't updated everything from backports is because the documentation on backports.debian.org says not to.

[emariz]

the main reason I haven't updated everything from backports is because the documentation on backports.debian.org says not to.

If one enables all Backports for automatic installation and adds the Debian Mozilla repository, which is literally a backports one, some libraries will be listed as upgradable, even though no package has been marked for installation yet.
Since one adds the Debian Mozilla repository to install Iceweasel/Icedove, and all those upgradable libraries are pulled as its dependencies, there should be no problem. This is the scenario that the developer faced and tested (a newer package pulling certain newer dependencies).

But when one adds a bigger/broader backports repository like Backports itself, several packages (mostly libraries) will be marked as upgradable, many of which would never be explicitly pulled as dependencies (unless one installed all available backports). Because this scenario was not considered by the developer, APT might have issues, like the one I faced with Network Manager.

Did it make things clearer?

[ivanovnegro]

A bit complicated but I also do not see any reason to install all backports, only the things I need in a newer version.

[emariz]

I just wanted to show a case where APT encounters a non-installable situation by enabling all Backports for automatic installation. This was relatively easy to solve but there might be difficult (or impossible) situations with other packages.

As of today, July 7th, that Network Manager issue no longer exists because network-manager-gnome was updated in Backports. It's still an example of what may happen any other day.

[Roel63]

I, too, enabled all Backports in Squeeze by giving Backports an apt-pinning of 500, and it worked well until a week ago.

Xorg was upgraded in Backports. However, this was done in bits and pieces, and also not all architectures were done simultaneously. This resulted in a non-installable xserver-xorg-core, because some inputs weren't handled yet.

On my 64-bits desktop, I just had to wait a few days and everything was resolved. On my 32-bits laptop however, i made the mistake to run "apt-get install -f", which turned things around and left me with a mouse that didn't work (perhaps the synaptics part was disabled? Don't know).

Of course it wasn't THAT hard to fix, but it is annoying. And a good advice NOT to use "apt-get install -f" in these cases.

After two days, all of Xorg was uploaded to Backports and I could upgrade my laptop as well. Good howto was given in the Backports mailing list when everything had been uploaded: http://x.debian.net/reference/squeeze-backports.html

I don't think one needs to be extra careful when enabling all backports. I DO think it's not the best thing to FORCE anything. I guess Backports isn't the main priority for developers and package maintainers, and, comparing emariz' network-manager story with this one, there can be some delay in dependency issues.

The reason I use Stable+Backports at the moment is that I like newer apps but suffered from a testing that broke on me just once too many. Other reason is that I am running Gnome2 and I'm not sure about slowly moving to Gnome3. So this is why I keep it this way, running a Sid Xfce install in a Virtualbox.

*edit* on a side note, the kernel is never upgraded automatically!

[emariz]

I, too, enabled all Backports in Squeeze by giving Backports an apt-pinning of 500, and it worked well until a week ago.

Xorg was upgraded in Backports. However, this was done in bits and pieces, and also not all architectures were done simultaneously. This resulted in a non-installable xserver-xorg-core, because some inputs weren't handled yet.

I don't think one needs to be extra careful when enabling all backports. I DO think it's not the best thing to FORCE anything.

I think that one needs some experience from administering Testing/Sid, but Stable + All Backports is definitely easier to maintain than those two. And, as you said, never force an installation. If a package set that you need isn't complete in Backports, hold the installation of the available packages for a couple of days until the developers finish the upgrade.

On my system, which uses an Intel video card and where I did a minimal Xorg installation, the recent upgrade to Xorg went smoothly (most likely because I didn't install the Wacom package). I still upgraded it from the command line, just in case.

on a side note, the kernel is never upgraded automatically!

It does if its meta-package from Backports is installed, like linux-image-686-pae or linux-image-amd64.

[emariz]

On June 17th, Aptitude warned me about another breakage while trying to update a backport:
gstreamer0.10-ffmpeg version 0.10.12-3~bpo60+1 is installed. Among others, it depends on libavcodec53 (< 5:0) | libavcodec-extra-53 (< 5:0). Right now, libavcodec53 version 4:0.8-2~bpo60+1 is installed. However, libavcodec53 has been updated to version 6:0.8.3-1~bpo60+1, which breaks the installed version of gstreamer0.10-ffmpeg.

The version of gstreamer0.10-ffmpeg in Testing and Sid has an updated dependency chain and accepts versions of libavcodec53 higher than 5:0. One can install gstreamer0.10-ffmpeg from Testing or Sid, or hold the update of libavcodec53 until the former is updated in Backports.

[emariz]

Today, June 26th rsyslog cannot be installed from Backports because it depends on initscripts (>= 2.88dsf-13.3), but it only exists at version 2.88dsf-13.1+squeeze1 in Squeeze.

gstreamer0.10-ffmpeg is still broken in Backports. At least, the problem has been reported:
http://lists.debian.org/debian-backport ... 00066.html

How could they miss such basic issues twice in the last couple of days?

[emariz]

The dependency chain of rsyslog was updated on June 29th; that of gstreamer0.10-ffmpeg, on July 3rd. Now both packages and their dependencies can finally be updated from Backports.