"2321" packages to upgrade . . . on reboot another "204" yet to go?? Why???

[non_space]

Gents:

I am an "enthusiast" . . . multi-booter type. Today is back in TW day and today's packages were "510" and it took roughly "30 mins" from when I clicked "y" to when the cursor returned . . . so more or less on par for the previous dl & install times . . . ??

I ran "dup" . . . "dupa" . . . "dup.service" . . . and "dupa.service" in Yast and got "no results found"???

I ran #inxi -CMSd and it shows my cpu speed as "1596 MHz" on a Xeon processor . . . definitely is SATA . . . TW is on an HDD . . . possibly SATA 2???

I would like to keep TW going due to the long term relationship that I have had with it, but not looking forward to the next "balloon" upgrade.

I could ask the gal at Gecko about the gcc package upgrade thing, she may or may not reply . . . as posted previously, when TW was running 2321 packages that same week Gecko found 1700 . . . and ran through a tad bit quicker than TW in the running of them . . . same machine, etc.

[Sauerland]

You're wasting your time.

He's clearly argumentative and does not even understand the basics of what rebuilding the entire system with a new compiler vs simply installing a different compiler version means.

You are right I read the last post.......

[non_space]

You are right I read the last post.......

These recent comments also seem "argumentative" to the OP. My point has been that to the end user it doesn't make that much difference whether the "entire system is recompiled" or whether just a "new compiler is installed."

The end result is similar as far as using the GUI is concerned. I would like to understand how to make processing these huge package upgrades simpler and more efficient, because for what is mainly a "daily" or rather a "weekly driver" having these huge hits of time and electricity to process them makes TW more cumbersome.

It is interesting how other regulars on this forum don't seem to be hitting these package tsunamis . . . .

[mrmazda]

I would like to understand how to make processing these huge package upgrades simpler and more efficient

Follow karlmistelberger's lead. Create services that dup daily, underneath whatever else is going on.

because for what is mainly a "daily" or rather a "weekly driver" having these huge hits of time and electricity to process them makes TW more cumbersome.

Big rebuilds are part & parcel of any rolling release. They're not as frequent on average as this thread makes them out to be. This one was rather tougher than average because of missed failures causing multiple major rebuilds in short succession, which isn't normal. IOW, the first of this latest series wasn't really ready.

It is interesting how other regulars on this forum don't seem to be hitting these package tsunamis . . . .

They're hitting what you're hitting. You're just reacting differently, in large part due to your infrequency of actually using TW. TW is not intended for people who are bothered by numerous updates. Best way forward for you, other than not using a rolling release, is probably to initiate dups manually at times you are leaving the house, going to bed, or about to start watching a movie.

[karlmistelberger]

Only when comparing comparables. I've been caching 64bit TW rpms on LAN server, and binding the cache to /var/cache/zypp/packages/. Thus, few files are being downloaded on each next of my 30 or so 64bit TWs, making time spent downloading lower than typical for TW users.

CPU time used by dup/dupa correctly reflects the effect of caching packages. Compare these values to typical Firefox session:

erlangen:~ # journalctl -b -1 -u dup -u dupa -g Consumed -q                                                                  
May 22 00:02:17 erlangen systemd[1]: dup.service: Consumed 4.790s CPU time. 
May 22 00:03:55 erlangen systemd[1]: dupa.service: Consumed 23.072s CPU time. 
May 23 03:43:28 erlangen systemd[1]: dup.service: Consumed 7.975s CPU time. 
May 23 05:35:57 erlangen systemd[1]: dupa.service: Consumed 22.442s CPU time. 
erlangen:~ #

erlangen:~ # journalctl -b -1 -g app-firefox-20a719d9bbdb487eb8bee8177abba915.scope -q 
May 23 07:28:59 erlangen systemd[1267]: app-firefox-20a719d9bbdb487eb8bee8177abba915.scope: Killing process 12119 (TaskCon~ller #6) with signal SIGKILL.
May 23 07:28:59 erlangen systemd[1267]: app-firefox-20a719d9bbdb487eb8bee8177abba915.scope: Consumed 4h 5min 17.957s CPU time.
erlangen:~ #

Zypper's fraction of above total is: (4 + 23 + 7 + 22) / (4 * 3600 + 5 * 60 + 17 + 4 + 23 + 7 + 22) = 0.4%. This is peanuts.

[malcolmlewis]

It is interesting how other regulars on this forum don't seem to be hitting these package tsunamis . . . .

Hi
I do, but just let it do it's thing in the background (as in download first, or run screen) and carry on doing stuff..... only some extra work here on a kernel update to manually rebuild the nvidia driver.

[nrickert]

My point has been that to the end user it doesn't make that much difference whether the "entire system is recompiled" or whether just a "new compiler is installed."

That may be true. But for openSUSE, Tumbleweed is used for testing new software that may eventually make it to Leap and SLE.

Maybe it isn't for you.

It is interesting how other regulars on this forum don't seem to be hitting these package tsunamis . . . .

We see them. We just deal with them when they come.

[non_space]

Follow karlmistelberger's lead. Create services that dup daily, underneath whatever else is going on.

Big rebuilds are part & parcel of any rolling release. They're not as frequent on average as this thread makes them out to be. This one was rather tougher than average because of missed failures causing multiple major rebuilds in short succession, which isn't normal. IOW, the first of this latest series wasn't really ready.

@mrmazda:

Thanks for those suggestions. I would be interested in Karl's suggestions, but as posted in checking in Yast on terms "dup" "dupa" . . . nothing shows up . . . .

And, thanks also for posting the "first of the series wasn't really ready" comment . . . that I believe is a statement of truth . . . .

CPU time used by dup/dupa correctly reflects the effect of caching packages. Compare these values to typical Firefox session:
[CODE]erlangen:~ # journalctl -b -1 -u dup -u dupa -g Consumed -q
Zypper's fraction of above total is: (4 + 23 + 7 + 22) / (4 * 3600 + 5 * 60 + 17 + 4 + 23 + 7 + 22) = 0.4%. This is peanuts.

Running the original post of this command brought the empty cursor . . . . Yast doesn't show "dup" or "dupa" . . . .

Hi
I do, but just let it do it's thing in the background (as in download first, or run screen) and carry on doing stuff..... only some extra work here on a kernel update to manually rebuild the nvidia driver.

Cool. We'll see how TW develops in the coming future.

That may be true. But for openSUSE, Tumbleweed is used for testing new software that may eventually make it to Leap and SLE.

Maybe it isn't for you.


We see them. We just deal with them when they come.

TW isn't the only rolling edition that I have or have used . . . but, perhaps after 6 years of using it . . . there may be "irreconcilable differences."

Using another OS, today was "Sid" day . . . the Sid guys on the forum take the same, "You don't know what you are doing" attitude on users of their fine offering when finding issues. BTW I run updates in all of my installs every week, today Sid had "103 packages" it dl'd and installed them in 3 or 4 minutes. Sid does everything fast. If I compare that time to the "505" packages that I upgraded in TW yesterday in half an hour . . . the Sid time beats TW by ten minutes . . . same "old" machine.

[mrmazda]

I would be interested in Karl's suggestions, but as posted in checking in Yast on terms "dup" "dupa" . . . nothing shows up . . . .
Running the original post of this command brought the empty cursor . . . . Yast doesn't show "dup" or "dupa" . . . .

As spelled out in post #58, dup and dupa are local services. Local in a config file name always means the admin is entirely responsible for their content; hence, neither rpm nor zypper nor yast would know anything about them, unless possibly created from a packaged skeleton file.

[awerlang]

BTW I run updates in all of my installs every week, today Sid had "103 packages" it dl'd and installed them in 3 or 4 minutes. Sid does everything fast. If I compare that time to the "505" packages that I upgraded in TW yesterday in half an hour . . . the Sid time beats TW by ten minutes . . . same "old" machine.

Oh debian sid again? I suppose it's gcc 12 / glibc 2.35 over there already. That is fast!