Why updates when no changes?
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? For example: - Update to 5.22.2.1 * New bugfix release * For more details please see: * https://kde.org/announcements/plasma/5/5.22.2 - No code changes since 5.22.1 Isn't that pointless and superfluous?
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 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". Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
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 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 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
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 Mi, 2021-06-30 at 18:12 +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.
Sure. Just saying that I have rarely seen it pay off in terms of actual elapsed time. Martin
On Wed, Jun 30, 2021 at 4:10 PM Martin Wilck <martin.wilck@suse.com> wrote:
It is a trade-off by design, less download size vs more CPU power to decompress the packages.
Sure. Just saying that I have rarely seen it pay off in terms of actual elapsed time.
It has never saved me any time whatsoever, in fact the opposite on hdds. it is one of those things that should be off by default. or be dependant of magic parameters if known "I have an slow or metered connection and available horsepower to take this hit"
On 01/07/2021 04.44, Cristian Rodríguez wrote:
On Wed, Jun 30, 2021 at 4:10 PM Martin Wilck <martin.wilck@suse.com> wrote:
It is a trade-off by design, less download size vs more CPU power to decompress the packages.
Sure. Just saying that I have rarely seen it pay off in terms of actual elapsed time.
It has never saved me any time whatsoever, in fact the opposite on hdds. it is one of those things that should be off by default. or be dependant of magic parameters if known "I have an slow or metered connection and available horsepower to take this hit"
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. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
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? Jon Cosby
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 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
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, 08 Jul 2021 13:56:28 +0200, Richard Biener wrote:
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.
That's the logical consequence I reached at that time, too :) I vaguely remember a chat with mls about that, but the checksum wasn't available in the defined format (so need to extend the format somehow).
Isn't the delta rpm somehow signed?
Sorry, I don't know about the current situation. Someone needs to re-check. Takashi
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
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
On 7/1/21 3:02 AM, Simon Lees wrote:
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.
Yes, but that's another scenario which also doesn't create any changelog entries to confuse users ;-). Adrian
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
participants (14)
-
Ahmad Samir -
Carlos E. R. -
Christophe Giboudeaux -
Cristian Rodríguez -
Dominique Leuenberger / DimStar -
Gui Do -
John Paul Adrian Glaubitz -
Jon Cosby -
Martin Wilck -
Martin Wilck -
Richard Biener -
Simon Lees -
Stefan Brüns -
Takashi Iwai