On 6/30/21 1:10 PM, Gui Do wrote:

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

Upstream is bumping the version numbers to keep the version numbers of the individual components in sync. It would probably confuse users if we omitted those new upstream versions from packaging. Adrian

On Mi, 2021-06-30 at 14:37 +0200, Stefan Brüns wrote:

On Mittwoch, 30. Juni 2021 13:13:18 CEST John Paul Adrian Glaubitz wrote:

...

On 6/30/21 1:10 PM, Gui Do wrote:

...

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

Upstream is bumping the version numbers to keep the version numbers of the individual components in sync. It would probably confuse users if we omitted those new upstream versions from packaging.

Adrian

Also, there are often translation updates - "no *code* changes".

Yes, sometimes its just a version bump, but not having the versions in sync would cause significant effort for all the persons actually doing the work, and may also cause confusion for the users - "why is foo at 5.22.1, and baz at 5.22.3".

The OP has a point. It doesn't necessarily have anything to do with upstream. It happens for packages with subpackages, and for _multibuild, too. More often than not, just a single (sub)package has actually been changed. But all other packages bump version or release, too, and have to be built, distributed and updated. It'd be great if we could be smarter about that. "Why is foo at a.b.X and bar at a.b.Y?" questions might get asked, but users could get used to this if they see the benefit. Martin

On 30/06/2021 14:37, Stefan Brüns wrote:

On Mittwoch, 30. Juni 2021 13:13:18 CEST John Paul Adrian Glaubitz wrote:

...

On 6/30/21 1:10 PM, Gui Do wrote:

...

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

Upstream is bumping the version numbers to keep the version numbers of the individual components in sync. It would probably confuse users if we omitted those new upstream versions from packaging.

Adrian

Also, there are often translation updates - "no *code* changes".

Yes, sometimes its just a version bump, but not having the versions in sync would cause significant effort for all the persons actually doing the work, and may also cause confusion for the users - "why is foo at 5.22.1, and baz at 5.22.3".

[...] Adding to the above, zypper supports deltarpms, so the download size is smaller between version pumps? (or is this with TW, and deltarpms aren't available there?). regards, -- Ahmad Samir

On 30/06/2021 16:28, Martin Wilck wrote:

On Mi, 2021-06-30 at 15:49 +0200, Ahmad Samir wrote:

...

Adding to the above, zypper supports deltarpms, so the download size is smaller between version pumps? (or is this with TW, and deltarpms aren't available there?).

In my experience, updating using deltarpms is slower than updating with full rpm downloads.

Martin

It is a trade-off by design, less download size vs more CPU power to decompress the packages. -- Ahmad Samir

On 6/30/21 8:43 PM, John Paul Adrian Glaubitz wrote:

On 6/30/21 1:10 PM, Gui Do wrote:

...

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

Upstream is bumping the version numbers to keep the version numbers of the individual components in sync. It would probably confuse users if we omitted those new upstream versions from packaging.

Beyond that we have a policy of rebuilding when dependencies change so even if we didn't make an update of "no code changes" the package would still be rebuilt and updated whenever other kde dependencies are so we may as well keep version numbers in sync. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Thu, 2021-07-01 at 10:32 +0930, Simon Lees wrote:

On 6/30/21 8:43 PM, John Paul Adrian Glaubitz wrote:

...

On 6/30/21 1:10 PM, Gui Do wrote:

...

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

Upstream is bumping the version numbers to keep the version numbers of the individual components in sync. It would probably confuse users if we omitted those new upstream versions from packaging.

Beyond that we have a policy of rebuilding when dependencies change so even if we didn't make an update of "no code changes" the package would still be rebuilt and updated whenever other kde dependencies are so we may as well keep version numbers in sync.

We do? Where? Not in Tumbleweed at least: there we use rebuild=local and trigger stuff that loses install deps (i.e. on soname changes in pkg A, pkg B might turn uninstallable, we trigger a rebuild of B) TW has not been using OBS' default, transitive mode, for years Cheers, Dominique

Hello, On Wednesday, 30 June 2021 13:13:18 CEST John Paul Adrian Glaubitz wrote:

On 6/30/21 1:10 PM, Gui Do wrote:

...

Why are there always so many KDE/Plasma packages updated and have to be downloaded and installed, although there are no code changes in the changelog? (...) - No code changes since 5.22.1

Isn't that pointless and superfluous?

There's a misunderstanding about what "No code changes" really means. To make it short: 1 - We release what upstream provides. The plasma and framework releases contain ~80 tarballs each and the KDE Gear ones are closer to 200. 2 - We're using the git logs to create the changelogs 3 - The scripts we use omit changes voluntarily: * Commits that are pushed and reverted * upstream changes marked as 'SILENT'. This could be translation updates or dependency bumps. So "No code change since ..." never really meant absolutely nothing changed in the tarball. HTH, Christophe

Hej, thx for all your replies. At least Christophe makes it clear.

On 02/07/2021 22.38, Jon Cosby wrote:

On 2021-07-01 03:38, Carlos E. R. wrote:

...

It is a problem to choose the default.

No deltarpms is nowdays faster, with the download speeds people normally have. However, normal rpms is more expensive for the few people that are on a metered internet connection. It costs them money to change the default. Speed calculation changes for people with a slow internet, too.

The problem is that people are not aware that they can tune for speed vs small downloads.

I wasn't aware. Where can this be set?

/etc/zypp/zypp.conf: ## Whether to consider using a .delta.rpm when downloading a package ## ## Valid values: boolean ## Default value: true ## ## Using a delta rpm will decrease the download size for package updates ## since it does not contain all files of the package but only the binary ## diff of changed ones. Recreating the rpm package on the local machine ## is an expensive operation (memory,CPU). If your network connection is ## not too slow, you benefit from disabling .delta.rpm. ## # download.use_deltarpm = true #CER download.use_deltarpm = false Look at other settings in that file to see if there is something else useful to you. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Thu, 8 Jul 2021, Takashi Iwai wrote:

On Wed, 30 Jun 2021 18:12:37 +0200, Ahmad Samir wrote:

...

On 30/06/2021 16:28, Martin Wilck wrote:

...

On Mi, 2021-06-30 at 15:49 +0200, Ahmad Samir wrote:

...

Adding to the above, zypper supports deltarpms, so the download size is smaller between version pumps? (or is this with TW, and deltarpms aren't available there?).

In my experience, updating using deltarpms is slower than updating with full rpm downloads.

Martin

It is a trade-off by design, less download size vs more CPU power to decompress the packages.

I checked the performance of deltarpm many years ago, and found that the actual time eater of drpm isn't about decompression but the step for contents or signature check (I forgot details); it requires compressing *again* the whole data to match with the original rpm file contents. If we skip that part, deltarpm would be quite fast.

Providing an alternate checksum/signature for the uncompressed data to check against might also work of course. Isn't the delta rpm somehow signed? Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

On 08/07/2021 13:52, Takashi Iwai wrote:

On Wed, 30 Jun 2021 18:12:37 +0200, Ahmad Samir wrote:

...

On 30/06/2021 16:28, Martin Wilck wrote:

...

On Mi, 2021-06-30 at 15:49 +0200, Ahmad Samir wrote:

...

Adding to the above, zypper supports deltarpms, so the download size is smaller between version pumps? (or is this with TW, and deltarpms aren't available there?).

In my experience, updating using deltarpms is slower than updating with full rpm downloads.

Martin

It is a trade-off by design, less download size vs more CPU power to decompress the packages.

I checked the performance of deltarpm many years ago, and found that the actual time eater of drpm isn't about decompression but the step for contents or signature check (I forgot details); it requires compressing *again* the whole data to match with the original rpm file contents. If we skip that part, deltarpm would be quite fast.

Takashi

I am by no means an expert on that subject, so that was my general understanding of what it's supposed to do. :) Thanks for the insights. -- Ahmad Samir