Hit into some issues with upgrades in TW taking at least an hour for only a few hundred packages . . . might have reduced that time factor a bit by removing one of the 8 linux distros I had running on my '12 Mac Pro . . . too soon to tell on that.
But, today, booted in TW for my once a week visit, package updater shows “1852” packages to upgrade . . . I guess that is relating to the new “v3” packages???
I’d like to avoid running the machine for a decade just to upgrade all of those packages, and then (historically speaking) another 2K packages in just a few days, etc as things get worked out . . . .
I have now no real need to upgrade the entire system, so I might “coast” a bit and just upgrade firefox every few weeks, or possibly just the kernel. I checked online and it does seem like from within FF it would show options to “download and install” the latest options, but, would there be a way to upgrade FF && newer kernel from running a simple console command??
Or, would this be something where using YaSt to find and install newer editions of FF and kernel would be the way to avoid running the machine using zypper to upgrade everything??
It would be better to start a “zypper dup” just before you go to bed, and then check in the morning. Yes, occasionally something might go wrong, but this will work most of the time.
No. Just look at the packages and you will see that it is related to the upgrade to gcc13. All packages need to be rebuild if you increase gcc version.
You could also have seen this by reading the last announcement for Tumbleweed snapshot 20230319.
Different words that have similar meanings, whether “v3” or “gcc” . . . it makes for a load of packages, which I believe TW just went through this essentially same massive upgrading only a couple three months back???
I scan the factory list-serve, but I have other stuff going on in my life these days.
OK, got it, best not to “cherry-pick” the packages . . . it’s not a matter of whether the zypper is run at night or in the day, it’s just the machine time on the old i7 cpu “electrical gas hog” . . . that is the issue. I only run the machine for a couple of hours in the morning, then shut it down, etc.
Likely this would be the time to dig out those scripts that run zypper “in the background” . . . but still have to keep the machine running while that is potentially using time and space to run the packages through . . . in the now considered “geriatric” machine . . . .
OK, thanks for that info. Historically it actually hasn’t been the download that takes the time, but the “dup-ing” of kernel and “wl” packages where zypper seems to hang for long periods.
I do have the “dup” script recommended by . . . the man from Bavaria (mfB) . . . can’t think of his name . . . which I could “start” . . . .
But, what is your suggestion exactly . . . #zypper ref && zypper up to just grab the packages??? Then once in cache run #zypper dup -l ???
After the 20230319 announcement I downloaded first, then installed, on my newest PC. Total installation phase time to dup was under 2.5 minutes for approximately 1,000 packages.
OK, well, I think for my '20 Sys76 laptop with possibly “10th gen” Intel cpu it too would rip through a large upgrade . . . .
On my '12 i7 . . . I’m still noticing variable time durations for processing of package upgrades . . . with the SUSE options taking more time, not for downloading, downloading is fast here . . . there are a few packages that seem to just “drag” . . . ???
And, then, it seems like you had “1000” packages, but upgrader showed me “1852” . . . so almost double . . . . I should therefore anticipate setting aside “5 minutes” for handling that upgrade . . . . : - )
I might take the advice to run it when I’m not wanting to use the machine, in a TTY and run it through . . . without watching the clock.