Debian Sid has been fairly stable during the testing freeze. I expected this to change once Squeeze was released. This morning when I ran smxi, the scripts did not mention removing anything connected with X. However, when I proceeded to dist-upgrade, the upgrade of xserver-xorg and xserver-xorg-common had broken dependencies and apt wanted to remove almost the whole system. I answered n to the question and got an option to keep these two packages at their current version.

My question is whether smxi should have handled this for me?
Back to top

smxi has a consistency check on the list of packages prior to the d-u and also user inputed holds. I've not had any issues on 32 bit yet so nothing I can say needs holding.
Back to top

If the packages to be removed are caused by version conflicts due to incomplete uploads to sid, then smxi has a backend option to put those packages on hold until the conflict is resolved.

That's assuming it's a generalized conflict, not just local to your system due to something you may have put on hold or whatever then forgotten about.

The best way to know if it's generalized is to search for the packages plus debian in google and see if anyone has filed a bug report, which usually happens within a few hours.

If it's a generalized thing, we can put the packages on auto hold/remove hold in smxi which will make for a clean transparent upgrade.

That requires the test case where the minimum packages to be held are discovered and posted.

packages to be removed are not packages like you note, they are packages that apt itself tells you are going to be removed in the upgrade, usually because they are obsolete or replaced by a new package version name.

Also depends widely if you are using apt-get or aptitude. Aptitude will often offer the WRONG first option as choice, since it seems to favor not upgrading core packages over removing them, which is obviously a huge failure of aptitude, but if you go down the list of choices, usually a later one is right and does what you wanted. smxi has zero way of knowing what aptitude will offer as choices.

If you have been using a gui manager, like synaptic, apt often has no idea what it has done and that can lead to oddities. The same goes for switching incorrectly from apt-get to aptitude, that can also lead to such issues, but that's usually user error not a generalized package version mismatch issue.
Back to top

@techAdmin: Thanks for the information.
Back to top

By the way, I've been notified that this is only a 64 bit problem, so if you're running 32 bit, you're fine. This is, by the way, why I only run 32 bit on my desktops.

Debian has had increasing problems in Sid with the 64 bit pool, I saw this before sid was frozen for the coming squeeze release, so not a surprise to see the first major break happen in the 64 bit pool.

Fixes, if it hits you, install squeeze xserver-xorg, all the packages that come in with that, then wait.

Best fix, just wait.

I've added in a red warning alert to smxi too now.

Apparently there's also an ffmpeg break coming in 32 bit, no details there yet though.
Back to top

I am running 32 bit. Like you, I only run 32bit even though I have a 64 bit machine. I still am experiencing the same issue and would question whether it is limited to 64 bit systems. I saw your warning this morning and will wait a while before I do a full-upgrade. This issue is being discussed on the debian forums also.
Back to top

ok, thanks for the update, I've updated smxi warnings. If you can let me know when that issue is resolved that would be helpful..

I'm going to have to collect the smxi backend warning group, but many have drifted off and may not even use Debian any more, I'll see.
Back to top

I will keep you posted.
Back to top

This problem is now solved.
Back to top