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...
