Call for testers: zypp tech preview
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. -- Benjamin Zeller<bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755;https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Tue, Aug 31, 2021 at 9:54 AM Benjamin Zeller <bzeller@suse.de> 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.
Is there a way I can force the new librpm backend at compile-time? I want to have Zypper on Fedora always use it because the standard backend is utterly broken on Fedora. We don't have the SUSE specific patches to RPM to make the standard backend even partially work properly on Fedora. -- 真実はいつも一つ！/ Always, there's only one truth!
participants (2)
-
Benjamin Zeller -
Neal Gompa