Thanks for this tech preview.

I did three tests up to now:

"regular" dup = zypper dup "super" dup = env ZYPP_SINGLE_RPMTRANS=1 ZYPP_MEDIANETWORK=1 zypper dup

test 1 notebook: lock libreoffice, regular dup to get snapshot 20210830, remove lock, super dup to get libreoffice update.

test 2 desktop: super dup to get multimedia packages update from packman.

test 3 notebook: super dup to get snapshot 20210831. desktop: regular dup to get snapshot 20210831.

All tests were successful. On test 3, the download with super dup was four times slower than regular dup. The snapshot was fresh so the "additional mirror rating" must have made a poor choice due to the ongoing mirror syncing.

Regards, Bruno.

On Tue, 2021-08-31 at 15:53 +0200, Benjamin Zeller wrote:

In the last months the zypp team worked on the basics for speeding up and modernizing the zypper/libzypp codebase. Some of those projects are now available to Tumbleweed and can be enabled and tested.

Please keep in mind that those changes currently are tech previews, so zypper might crash or even break your system.

New RPM transaction backend for zypper: Traditionally zypper executes rpm separately for each operation in a transaction. This requires some hacks and workarounds and is not fully compatible to running all operations in one single transaction.

It is also a lot slower for big transactions ( like dup with many packages ). Therefore we have implemented a new backend that runs all operations in a single big transaction via librpm. It can be enabled by setting: ZYPP_SINGLE_RPMTRANS=1 in zyppers environment.

Issues/Changes with ZYPP_SINGLE_RPMTRANS=1 zypper ... :

• Changes how file conflicts work, since they are now executed by

librpm we are not able to generate a callback to ask the user if the error should be ignored.    In the presence of file conflicts, the transaction will report an error and will not execute unless --replacefiles is also used.

• Currently there is also a issue that could potentially break your

system in very specific preconditions. We put in a safety net that will protect you on Tumbleweed,    however it still remains a issue for all systems that are PREUsrMerge and use the single transaction mode to apply the update.    For example if you are on Leap and want to  upgrade to Tumbleweed.

This is the bug in question:    https://bugzilla.suse.com/show_bug.cgi?id=1189788

• Breaks Yast / PackageKit softwaremanager if enabled system wide: Due

to changes in the reporting , especially new reports, this would break the Yast software manager and Packagekit,    so if you use one of the two technologies enable this feature explicitly per command: `env ZYPP_SINGLE_RPMTRANS=1 zypper dup`.

New zypper HTTP backend: Another project we have been working on is parallelizing downloads, for this a new async downloader backend was implemented. While it currently won't have massive impact on performance due to the frontend code not requesting files asynchronously, it will do some additional mirror rating and as soon as we update the frontend code will bring more benefits.

This can be enabled via setting the env var: ZYPP_MEDIANETWORK=1

If you find any bugs or issues please let us know.

Preferably via:    https://bugzilla.opensuse.org/    Product:   openSUSE Tumbleweed    Component: libzypp (or zypper if available)

And please attach the /var/log/zypper.log to the bugreport.

it seem to sometimes fail while retriving packages from my own home:sp1rit OBS repo. ``` zypper: /home/abuild/rpmbuild/BUILD/libzypp-17.28.2/zypp- core/zyppng/base/signals.h:193: zyppng::Signal<R(T ...)>::~Signal() [with R = void; T = {}]: Assertion `this->impl()->exec_count_ == 0' failed. [1] 26832 IOT instruction sudo env ZYPP_SINGLE_RPMTRANS=1 ZYPP_MEDIANETWORK=1 zypper dup ```

https://bugzilla.opensuse.org/show_bug.cgi?id=1190199

Regards, Florian "sp1rit"

I just ran: `env ZYPP_SINGLE_RPMTRANS=1 ZYPP_MEDIANETWORK=1 zypper dup --download-only`

And trying to run a regular dup (without --download-only) did not display the packages as being already cached. I had to re-download them all again when running `env ZYPP_SINGLE_RPMTRANS=1 ZYPP_MEDIANETWORK=1 zypper dup`

Other than that, the upgrade went flawlessly, and these features are really useful. Thanks a lot for the incredible work!

Benjamin Zeller writes:

New RPM transaction backend for zypper: […] It can be enabled by setting: ZYPP_SINGLE_RPMTRANS=1 in zyppers environment.

I've been updating to Tumbleweed machines with this backend for some time and it works really well.

New zypper HTTP backend: Another project we have been working on is parallelizing downloads, for this a new async downloader backend was implemented.

This on the other hand has been problematic. The backend often choses mirrors that are extremely slow (on the other side of the globe or something that seems to be feeding its upload through a DSL line) and just won't stop using these. The most common symptom is that the download of a large file start off at full wire speed until it's somewhere in the 80% region and then drops off to modem speeds until finally all bits have arrived. If one of the servers of a multi-chunk download is a lot slower than the others, that download should be retried elsewhere.

While it currently won't have massive impact on performance due to the frontend code not requesting files asynchronously, it will do some additional mirror rating and as soon as we update the frontend code will bring more benefits.

At least a download-only dup should be able to fire off the downloads of multiple files in parallel. This is quite well supported in libcurl (you don't need multiple threads for that). If you complete the downloads in issue order, the output could be kept the way it appears today with the synchronous backend (but you wouldn't see the progress on the downloads that are started after the current front-of-queue one).

Regards, Achim.