On 10/15/21, Andrei POPESCU <andreimpope...@gmail.com> wrote: > On Jo, 14 oct 21, 13:19:09, Victor Hugo Muñoz wrote: >> >> Yes, I know the risks :-) My office computer is in stable for that >> reason. This is my home computer. Anyway, >> I'm extremely conservative with upgrades, and do not upgrade if I >> think I'm going to break something important, This may >> be the first major issue I've had for years in this particular machine. > > Postponing upgrades (of some packages) for a while (days or weeks, at > most) is indeed a necessity from time to time in unstable. > > However, at some point you do have to deal with it somehow[1] and let > the system reach current unstable, otherwise you'll encounter a > situation that is not supported at all (like managing packages from > current unstable with a 'dpkg' from pre-stable). > > [1] this may involve removing a specific package that is causing the log > jam.
I used to postpone because I didn't understand how the system works. My count at one time was over 1,000 packages on hold. What it seems to be most often is that there will be a package version number change. That logjam.. very often is that a User's choice of e.g. apt, apt-get, or aptitude needs to bring a brand new package onboard. Occasionally, it's even about bringing on more new packages beyond that version change. It's all about progress and package feature changes. My a-sumption about it is that they're graciously allowing Users the opportunity to consciously approve a new package coming into one's system. That new package addition even more frequently then requires one to manually delete the prior version of the newly added package. What I experienced and FREAKED OUT about (here on Debian-User) a couple years back was that a massive stable package deletion can occur if one suddenly decides to simultaneously upgrade ALL of those 1,000+ packages one might have postponed. If you nibble at it instead, that massive deletion usually does not occur. In fact, that logjam starts opening up and throwing packages into a normal upgrade priority after just the right postponed package is upgraded by adding in its newest dependency. Something like that... there. N.B. Linux-image on hold is a slightly different beast. Part of that is that its upgrade can render some systems unbootable until things are manually updated within one's CHOICE of boot managers. For example, I use LILO and have a separate directory that I maintain to help it function. I have to manipulate the latest vmlinuz and initrd.img files within that dedicated folder then everything continues to boot successfully after that. Thank you, Developers! Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
