Buster and apt wanting to remove tons of packages...
Hello everyone! I had an installation of debian stable (stretch) which was fully upgraded something like a couple of months ago. Then I passed it to testing (buster). Now I'm facing this situation: * 5031 installed packages * 1292 upgradable packages If I do a normal upgrade, 676 packages are to be upgraded, but only the gtk/qt unrelated ones (for example, apache2-doc but none of the apache2 *real* packages, or vim-addon-manager and vim-doc but none of the vim *real* packages, and so on) And if I try to upgrade, let's say, vim-* packages, it wants to remove a ton of seemingly unrelated packages, like calibre, evolution, gir1.2-*, gstreamer things, kid3, libqt5-*, pidgin, vlc-*, etc etc... This happens when I try to upgrade or install apparently *anything* related to GUI programs (GTK/Qt related). I am worried to make an upgrade like that. What can I do to debug this situation and try to understand which package(s) is/are breaking everything? I have no pinned packages. Thank you in advance!
Re: Buster and apt wanting to remove tons of packages...
On Tue, 2018-07-10 at 10:13 -0400, The Wanderer wrote: > If I were experiencing a similar situation, what I'd do is try to > simultaneously install both one of the packages that triggers the > cascade and one or more of the packages which the cascade wants to > remove, and keep adding packages to the install command until I get a > dependency-resolution failure. > > E.g., assuming that trying to upgrade 'vim' triggers the cascade and the > cascade wants to remove calibre, evolution, and pidgin: > > $ apt-get install vim calibre evolution pidgin > > (In case it wasn't obvious: an 'install' operation on an > already-installed package which has a newer available version triggers > an install of that newer version, i.e., an upgrade.) > > If you get a successful upgrade attempt which doesn't trigger the > cascade, you can let it proceed, then try the mass upgrade again. If the > mass upgrade still produces the cascade, you can repeat the > some-small-subset-of-packages manual install process. > > If on the other hand the manual install command *does* trigger the > cascade, you should cancel it and add more package names to the install > command. > > Keep repeating those two until either the cascade disappears from the > mass-upgrade attempt, or you get a "request cannot be fulfilled" > dependency-resolution failure. > > If the cascade disappears along the way, you're in good shape; just > complete the mass upgrade. (Unfortunately, this doesn't really help > figure out what caused the bug in the first place.) > > If you get a dependency-resolution failure, the packages involved should > give you a hint about which packages have dependency relationships which > are leading to the cascade. This seems like a long work, but it's a path I did not think about, maybe I'll try this steps, thank you for the hint! > The next step involves looking at those packages and their dependency > relationships, and I can't describe the process very well without a > real-world example to hand. Yes, I know, but listing the hundreds and hundreds of packages involved can be annoying for the mailing list... :) > Once you've identified the dependency relationship which resulted in the > cascade, it's probably fairly straightforward to determine what bug > report to file and what package to file it against. If I'll manage to point the finger to the package that triggers all this mess, I'll do a bug report.
Re: Buster and apt wanting to remove tons of packages...
On Tue, 2018-07-10 at 16:29 +0200, Hans wrote: > Please also note, tzhat there is a difference, between using apt (apt-get) > and > aptitude. > > The way, I prefewr, is using apt-get upgrade (which installs only newer > packages, and let the problematic ones uninstalled), then using apt-get full- > upgrade. > > When there are packages deinstalled, reinstall them afterwards. > > I know, this is not the best way. > > As itr was mentioned before: Using aptitude (tzhe ncurses gui) can show you, > which packages are causing trouble. You can set them to hold (aptitude hold > packagename) and then analyse, what dependencies are causing the trouble. > > One package after the other. Yes, it is annoying, I agree. > > Hope this helps still > > Best regards > > Hans Thank you for your hint, I never used aptitude, so I think I have to RTFM about it and see if it helps me in my situation :)
Re: Buster and apt wanting to remove tons of packages...
On Tue, 2018-07-10 at 22:00 +0200, Jochen Spieker wrote: > sgarrulo: > > > > I had an installation of debian stable (stretch) which was fully upgraded > > something > > like a couple of months ago. Then I passed it to testing (buster). > > There should not be that many changes, but I generally would only > upgrade to a newer release when the current system is up-to-date with > regards to its current version. Ops, I think I made myself not as clear as I thought, sorry... (english is not my mothertongue) I meant that a couple of months ago, my machine was on stable, and fully up to date. Then one day, two months ago, when my machine was fully up to date to stable, I made the switch to testing, because Being passed many months since the release of stretch, I thought that the hurricane (that happens right after the release of a new stable) in testing was passed. Oh boy how I was wrong... :P > You can use aptitude's TUI to investigate these things. It should at > least help explain why this happens. It is very possible (or likely), > that testing is just in bad shape for this upgrade right now. I never used aptitude, but I think I'll RTFM and try to understand the situation better > Aptitude. I do not like how it behaves and how you control it, but for > this kind of investigation it is without alternative. Instead of the TUI > you can also use 'aptitude why' and 'aptitude why-not'. > Thank you, I'll do it!
Re: Buster and apt wanting to remove tons of packages...
On Tue, 2018-07-10 at 14:08 +0100, Joe wrote: > > What I do is to temporarily switch from upgrade-system to Synaptic. It > is relatively quick to select a few innocent-looking packages from the > big list, and check that they go through without a problem. After a few > tries, you can see where the trouble is, and leave those packages at > the current state. People comfortable with the aptitude interactive > interface can do the same there, but for some reason, I prefer > Synaptic. Generally the state of difficulty lasts only a few days, > though it can go on for a week or two sometimes. I also tend to do something like that, but I'm worried that upgrading like this can broke things badly, especially when upgrading shared libraries, or some (but not all) packages related to a program. For example, I don't know.. Situation like "yeah, I'll upgrade my terminal because it's harmless", and then it stops working because I did not upgrade also lib-foo-bar-baz which is used by my terminal. So let's upgrade lib-foo-bar-baz! but I cannot upgrade it now because trying to upgrade it wants to remove a ton of other software that I use. And maybe I cannot install another terminal either because it's GUI software, which installation triggers all the cascade of removal of other things, etc etc etc... You can say "no, something like that cannot happen" but Murphy's law is always right behind the corner. > It's the price you pay for having more up-to-date software than stable > has. At the point of release of a new Debian stable, testing is > identical to it. At the time of the next release, about two years > later, testing is very different, many changes of architecture of major > systems having been made. If you use testing or unstable over this > period, you have to ride out these upheavals, hoping that nothing > important breaks. About eighteen months after release, testing is > frozen for bug fixing before the next release, and the ride is much > smoother after that. It's quieter in unstable as well, since unstable > has to be kept in a condition where it can be copied into testing after > the release occurs, so changes to unstable have to be kept within > limits. All hell breaks loose at release time... Yes, I know the basics of Debian release cycle. I had sid and testing on this computer before. When the freeze approaches I keep $codename (of the to-be-released stable distribution) in my sources.list and keep my machine on stable for some time after the release. But I thought that 2018's spring/summer was enough time after the release of stretch to try and be on testing again...
