Synaptic decides on its own not to upgrade packages
 

Hi there,

every other week or so I find something strange when I open Synaptic package manager on my Ubuntu 10.10 (maverick). Without my wanting so, Synaptic seems to decide randomly to withhold and not update some packages.

Today, for instance, I found that Synaptic had decided to lock cups-pdf and xulrunner to the currently installed version; a few days ago it was apache2. When I find that, I mark the packages manually for updating, and Synaptic does so without complaining. And next week, it's the same with some other package.
I don't see any pattern as to when and why this happens, or which packages are picked for the trick.

Anyone ever had that? What is it that makes Synaptic withhold certain updates for no apparent reason?
I'm confused about that, and have been for months.

Thanks in advance for your hints.

[X] Doc CPU

Um... That's not an amazingly helpful link, amani... Unless the answer is actually in there and you can point us to it :P otherwise, it's just a massively long document, which doesn't seem to mention the issue.

I'm afraid, Doc, I can't find any reference to your problem on the internet. Have you considered switching to a different distribution? Or even just upgrading to a more recent version of Ubuntu. :)

Hi there,

I quickly scanned that manual chapter and couldn't find anything that seems to be related to my problem.
But maybe I missed an important detail, so please be more specific.

[X] Doc CPU

Hi there,

exactly what I thought. :-)

Neither could I. That's why I'm asking here.

For my desktop system I'm quite happy with Ubuntu and don't want to change to another distro (bearing in mind that it takes weeks to get a different system running and properly customized), though for special purposes I'm also using and experimenting with other distros: Gentoo for my server, Tiny Core or Puppy for small embedded systems. And reading about all the trouble Ubuntu 11.x seems to cause, I'm not very keen on upgrading the base system.

After all, as I seem to be the only one having this problem, it's certainly not a general Ubuntu or Synaptic issue. On the other hand, I didn't change Synaptic's default settings, other than adding repositories for Opera, VirtualBox and cc65.

Thanks anyway for you suggestions.

[X] Doc CPU

Try updating from the command line, as you'll get detailed output that may shed light on the discrepancy. (Copy & paste the output back here.)

No, you're not the only one. I've seen it too.

The packaging system uses some kind of internal algorithm for comparing package dependencies and handling conflicts, and sometimes the order in which packages get updated is important.

This likely gets very complex when there are dozens/hundreds of packages being updated at the same time. My guess is that there are occasionally ordering conflicts that it just can't process automatically, and so it simply drops those from the automatic update. But when you reduce the problem to just one or a few packages, it's able to resolve the dependencies cleanly.

Since I don't update my system very often, the number of packages involved when I do is usually very large. From experience I've learned not to depend on it doing everything correctly on its own, and so now I break it up into multiple smaller updates, so that I can monitor what it's trying to do more carefully. It cuts down on major surprises.

Hi there,

so you're saying that this is not the way it's intended to work, but given the fact that no system is fault-free, that's normal in a way? Like people don't intend to get ill, but it's normal that they do once in a while?

After all, your explanation makes sense to me, although I run updates every four to six weeks and there's rarely more than a dozen packages that need updating. And once I know about that flaw, I don't mind handling it manually.
But you know, whenever something doesn't work the way I expect, or for example my car is making noises it isn't supposed to, I'm concerned about it. As soon as I know the reason, and I know I can't fix it but it's harmless, I can live with it. And that's probably what I'm going to do about this issue, too.

@snowpine:
I ran an apt-get update and examined the output, and there was nothing I considered suspicious, although I don't know why some lines appear more than once:
However, I won't run dist-upgrade blindly since a distro upgrade is exactly what I don't want. I always want to see every single package that is about to be updated, and I want to be asked for it - just the way it works with the automatic update-manager.

[X] Doc CPU

I prefer dist-upgrade vs. GUI tools like Synaptic/Upgrade manager, because the output is more verbose & helpful. I don't know why you call command-line method "blind." In fact apt-get will list every available update and then ask you "Yes/No." You answer "No," then copy & paste the terminal output here and we all take a look. It is a forum-friendly alternative to taking lots of screenshots of Synaptic. Your call. :)

(edit) You can also use "apt-get -s" flag which will "s"imulate an upgrade for diagnostic purposes.

Hi there,

you misunderstood me. In fact, I do prefer command-line to GUI solutions. But only if I know exactly what they do. A GUI approach like Synaptic as a frontend to apt-get is usually more hassle to work with, but often offers information more clearly and with less user interaction.

There you go! *That's* what I was talking about when I used the word "blindly". I didn't know if I'd have a chance to intervene once I started the process, and I wasn't going to risk that. I do anything to avoid involuntary changes to my system configuration. Difficult in Windows, a bit easier in Ubuntu.

I fully agree to that.
Here's the output of apt-get -s dist-upgrade. It's a very short one: ;-)
But as I mentioned before, I think David the H. explained the phenomenon sufficiently.

[X] Doc CPU

Excellent! Next time you have a discrepancy in Synaptic you'll have an additional diagnostic tool at your command.

By the way people sometimes get confused about "upgrade" vs. "dist-upgrade" I know I was at first. It sounds like dist-upgrade might upgrade you to the latest 11.10 or whatever, but actually that's called "release upgrade." In fact the difference between "upgrade" vs. "dist-upgrade" is that the former will not add/remove any packages, such as a kernel upgrade (each kernel version is a separate package which is why you can have multiple options in GRUB), whereas a dist-upgrade will. You can think of them as "safe" and "full" upgrades if you like, or even use the -s flag and compare the difference, next time you have upgrades available of course. It might even give you a clue as to the Synaptic behavior.

You always get the option to continue or not in apt-get.

You get exactly the same information you get from Synaptic on upgrades as you do in apt-get.

You can always interrupt a process in apt-get by hitting Ctrl+c.

You can also use Ctrl+d to exit the terminal (or tab as the case may be). This does not leave an "exit" command in your history so that you have to wade past it to get to your last "real" commands.

I do not know if you have ever looked at the Edit>Preferences>General tab in Synaptic. If you check all the boxes EXCEPT the bottom one, you will have a lot more information from it than you do now, including the ability to scroll back through the install process to see what errors there may have been.

Unlike the real terminal once that window is closed it is gone for ever so if you want to look at it do it right then.

Hi there,

yes, that's fine - but I didn't know until today.

But then it might already be too late - that was my concern.

I haven't merely looked at those settings, I considered for every single one of them if I could agree with the default. And yes, I have the check marks as you describe them, except I also removed the check mark at "Clicking on the status icon marks the most likely action", because I don't want Synaptic to guess what I'm gonna do.

Anyway, that last block of your quote was clearly a plea *for* Synaptic, whereas initially you seemed to defend the command line approach. ;-)

[X] Doc CPU

In terminal you have the choice before running the upgrades as to whether you want to or not. This is the same as in synaptic.

In either case, if the process is interrupted it will not finish any of it. It will have to be started over other than the downloading of packages.

In Synaptic you have no graceful way to do this other than kill synaptic.

In the terminal you could do that too but Ctrl+c is less traumatic on the system.

The option in Synaptic to give the most likely option does not mean you have to follow it. It is handy in case of a broken package.

I like Synaptic as a gui. If you need a gui that is the one to use.

I prefer apt-get as my main package management tool. Aptitude comes second. Then synaptic which I really like to use to look at what is available and what is and what is not installed. Apt-get and aptitude will do those things too but synaptic is easier on my eyes for those jobs. For every thing else it is easier to get information from either of the others.

If synaptic, for instance, will not install a package you really get no info of use in getting it installed. "aptitude why-not <package>" will give you that information.

I really like aptitude for the very special commands that only it has that make life so much easier. I only use it a bit but that bit is just great.

Apt-get is the real work horse for me. The -s option of simulating an install, for instance. when you are not sure of something is a stress saver.

I thought the apt manual would be there.


The apt-get manual says:
"New versions of currently installed packages that
cannot be upgraded without changing the install status of another package will be
left at their current version. An update must be performed first so that apt-get
knows that new versions of packages are available."

It can happen that apt-get disallows package X to be upgraded but Synaptic permits it. This has happened for example with kernels in *buntu.

read
man apt_preferences

and how to change policy.

...It is ALL there


But it can be improved by using the actual dependency tree.