Zypper vs Packagekit

Mikhailo · June 10, 2021, 2:57pm

After update from Leap 15.2 to 15.3, I have got packages conflicts. “zypper refresh” and “zypper update” works fine without errors. But packagetkit in KDE shows notifications about updates. I expected that packagekit uses the same information about updates as zypper. So, I think if zypper installed an update, packagetkit will not try to install it. However, packagekit (and its entry in KDE systen tray) annoyingly wants to install patches, while “zypper update” doesn’t want to install anything.

“zypper lr” output:

#  | Alias                       | Name                                                                                        | Enabled | GPG Check | Refresh
---+-----------------------------+---------------------------------------------------------------------------------------------+---------+-----------+--------
 1 | Packman                     | Packman Repository                                                                          | Yes     | (r ) Yes  | Yes
 2 | games                       | games                                                                                       | No      | ----      | ----
 3 | kernel-repo                 | kernel-repo                                                                                 | No      | ----      | ----
 4 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No      | ----      | ----
 5 | repo-backports-update       | Update repository of openSUSE Backports                                                     | Yes     | (r ) Yes  | Yes
 6 | repo-debug                  | openSUSE-Leap-15.3-Debug                                                                    | No      | ----      | ----
 7 | repo-debug-non-oss          | openSUSE-Leap-15.3-Debug-Non-Oss                                                            | No      | ----      | ----
 8 | repo-debug-update           | openSUSE-Leap-15.3-Update-Debug                                                             | No      | ----      | ----
 9 | repo-debug-update-non-oss   | openSUSE-Leap-15.3-Update-Debug-Non-Oss                                                     | No      | ----      | ----
10 | repo-non-oss                | openSUSE-Leap-15.3-Non-Oss                                                                  | Yes     | (r ) Yes  | Yes
11 | repo-oss                    | openSUSE-Leap-15.3-Oss                                                                      | Yes     | (r ) Yes  | Yes
12 | repo-sle-update             | Update repository with updates from SUSE Linux Enterprise 15                                | Yes     | (r ) Yes  | Yes
13 | repo-source                 | openSUSE-Leap-15.3-Source                                                                   | No      | ----      | ----
14 | repo-update                 | openSUSE-Leap-15.3-Update                                                                   | Yes     | (r ) Yes  | Yes
15 | repo-update-non-oss         | openSUSE-Leap-15.3-Update-Non-Oss                                                           | Yes     | (r ) Yes  | Yes

“pkcon update” output:

Getting updates               =========================]          
Finished                      =========================]          
Refreshing software list      =========================]          
Testing changes               =========================]          
Finished                      =========================]          
Fatal error: the to be installed patch:SUSE-2020-3291-1.noarch conflicts with 'python2-redis < 3.4.1-3.3.1' provided by the installed python2-redis-3.4.1-lp153.1.85.noarch
the to be installed patch:SUSE-2021-1499-1.noarch conflicts with 'webkit2gtk-4_0-injected-bundles.x86_64 < 2.32.0-3.74.1' provided by the installed webkit2gtk-4_0-injected-bundles-2.32.0-3.15.1.x86_64
the to be installed patch:SUSE-2021-1917-1.noarch conflicts with 'python3-libxml2-python.x86_64 < 2.9.7-3.37.1' provided by the installed python3-libxml2-python-2.9.7-3.34.1.x86_64
the to be installed patch:SUSE-2021-1926-1.noarch conflicts with 'libstdc++-devel.x86_64 < 7-3.6.1' provided by the installed libstdc++-devel-7-3.3.22.x86_64
the installed libavformat58-4.2.1-pm152.3.17.x86_64 requires 'libopenmpt.so.0()(64bit)', but this requirement cannot be provided
the to be installed patch:SUSE-2021-1897-1.noarch conflicts with 'libX11-xcb1.x86_64 < 1.6.5-3.21.1' provided by the installed libX11-xcb1-1.6.5-3.18.1.x86_64
the to be installed patch:SUSE-2020-2950-1.noarch conflicts with 'python3-pycryptodome.x86_64 < 3.9.0-3.3.2' provided by the installed python3-pycryptodome-3.9.0-1.44.x86_64
the to be installed patch:SUSE-2021-1200-1.noarch conflicts with 'libreoffice-writer-extensions.x86_64 < 7.1.2.2-13.15.1' provided by the installed libreoffice-writer-extensions-7.1.2.2-2.3.x86_64
the to be installed patch:SUSE-2021-1569-1.noarch conflicts with 'libreoffice-writer.x86_64 < 7.1.3.2-13.18.3' provided by the installed libreoffice-writer-7.1.2.2-2.3.x86_64
the to be installed patch:SUSE-2021-1819-1.noarch conflicts with 'gstreamer-plugins-ugly-lang < 1.16.3-3.3.1' provided by the installed gstreamer-plugins-ugly-lang-1.16.2-pm153.2.3.noarch
the to be installed patch:SUSE-2021-1944-1.noarch conflicts with 'gstreamer-plugins-bad-lang < 1.16.3-9.3.1' provided by the installed gstreamer-plugins-bad-lang-1.16.2-pm153.4.3.noarch

How can I resolve this situation with packagekit? I don’t want to disable it.

dcurtisfra · June 10, 2021, 3:28pm

It ain’t an Update – it’s an UPGRADE …

Please follow either the UPGRADE
instructions here – <https://en.opensuse.org/SDB:System_upgrade>. - Or, download the Leap 15.3 ISO image, boot it and, follow the UPGRADE
instructions …

After the Upgrade has completed, you’ll need to also execute “rpmconfigcheck” to step through the configuration changes and, “rpm --verify --all” to check for any missing files. When that has been completed, also check for any orphaned packages.
[HR][/HR]With Leap 15.3, there are some major changes to the repository scheme – please read the Release Notes – <https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/index.html>.

OrsoBruno · June 10, 2021, 4:36pm

There are still some problems with patches in Leap 15.3; see for instance here https://forums.opensuse.org/showthread.php/554949-New-updates-via-Applet-fails
just ignore / disable the applet for the time being and use “zypper update” as you did already.

Mikhailo · June 10, 2021, 4:57pm

Oh yes, of couse, upgrade. This was just a typo. I followed the description in Opensuse wiki, I used opensuse since 2012, so this is not the first upgrade for me. I just cannot understand why packagekit gives errors but zypper doesn’t.

For example, I see packagetkit error *"*the to be installed patch:SUSE-2021-1569-1.noarch conflicts with ‘libreoffice-writer.x86_64 < 7.1.3.2-13.18.3’ provided by the installed libreoffice-writer-7.1.2.2-2.3.x86_64, zypper shows the installed version of libreoffice =7.1.2.2-2.3. I run Yast and checked the repositories. I have found the libreoffice is located in two repositories: “SUSE Linux Enterprise 15” (v 7.1.3.2) and “OpenSUSE-Leap-15.3-Oss” (v 7.1.2.2). Libreoffice has several packages, and only small part of them of them located in “SUSE Linux Enterprise 15”. I think the source of problem is here.

tannington · June 10, 2021, 6:08pm

Work in progress, being tracked (mostly) in this bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1186642

For the moment it is best to just use zypper up, rather than patch or packagekit…

Mikhailo · June 10, 2021, 7:08pm

OrsoBruno, tannington, thank you. I masked the packagekit service and will wait for the problem gets fixed.

karlmistelberger · June 10, 2021, 7:51pm

Masking a unit is brute force and should be used only if everything everything fails. Disabling the software updater in the system tray settings does the trick and comes with no side effects. I configured packagekit-background.timer to perform a daily check for new updates and send mail upon updates being available.

**erlangen:~ #** systemctl list-unit-files packagekit*                          
UNIT FILE                         STATE   VENDOR PRESET
packagekit-background.service     static  -            
packagekit-offline-update.service static  -            
packagekit.service                static  -            
packagekit-background.timer       **enabled ****disabled     **

4 unit files listed. 
**erlangen:~ #**

hcvv · June 10, 2021, 8:17pm

Is that based on documentation or is this your personal meaning?

I have gone one step further. PackageKit is not installed on my system.

nrickert · June 10, 2021, 8:35pm

I’m not sure what’s the urgent need to know.

I just run updates twice per week, and then reboot. Occasionally, I find that there aren’t any. But there are usually a few updates.

karlmistelberger · June 10, 2021, 9:27pm

From https://fedoramagazine.org/systemd-masking-units/:

This is the third level of “off” in systemd. If you boot with a unit masked, it will not run even to satisfy dependencies. Masking is powerful for this reason. But like other powerful commands, you should use it carefully. If you mask an important unit (like the aforementioned system.slice), you could stop your system from booting normally.

Common sense tells me to minimize side effects. Masking has side effects. Disabling the applet has no side effects.
Evidence tells me Software Update Manager for Plasma is the culprit. Based on evidence I choose to turn it off on a user level. This is my personal decision. No personal opinion involved. Other users on the machine are unaffected by my decision. They can even update the machine using the applet.
Uninstalling package plasma5-pk-updates removes the applet for everybody.

karlmistelberger · June 10, 2021, 9:34pm

There is no urgent need to know. Mail from packagekit moves to the local mail folder ‘openSUSE’. This folder is a common place of information related to openSUSE. That’s all.

hcvv · June 10, 2021, 9:51pm

I have of course also the plasma5-pk-updates not installed. I am not willing to go to all my users desktops and disable the applet there (where they then will probably be able to enable it again).

And I do not need PackageKit at all. I use YaST/zypper, one of the main reasons to use openSUSE.

And I masked e.g. Wicked (using systemd-networkd). I see no problem with that.

karlmistelberger · June 11, 2021, 8:08am

I see. With plasma5-pk-updates deinstalled the applet is gone of course. Polkit authorizes users to run these:

karl@3400G:~> LANG=C pkcon get-updates
Getting updates               =========================]         
Querying                      =========================]         
Refreshing software list      =========================]         
Finished                      =========================]         
There are no updates available at this time.
karl@3400G:~> LANG=C pkcon update
Getting updates               =========================]         
Finished                      =========================]         
No packages require updating to newer versions.
karl@3400G:~>

And I do not need PackageKit at all. I use YaST/zypper, one of the main reasons to use openSUSE.

I use PackageKit for mail notification and ‘zypper dist-upgrade’ for performing the upgrade. On rare occasions I browse the system with ‘yast2 sw_single’ GUI. openSUSE offers several options. Users can select what fits them best. That’s why I use openSUSE.

And I masked e.g. Wicked (using systemd-networkd). I see no problem with that.
Policy here is: Avoid unnecessary actions. Write down what is necessary, e.g. https://forums.opensuse.org/showthread.php/540572-Installing-Packman-Codecs

Regarding systemd I run systemd-delta on a regular schedule and watch for changes made. Common sense and experience tells me to keep the list of of changes at the minimum required to perform tasks configured:

[FONT=monospace]**3400G:~ #** systemd-delta --type overridden  
**[OVERRIDDEN]** /etc/systemd/system/packagekit-background.service → /usr/lib/systemd/system/packagekit-background.service 
**# vendor killed configuration through **[/FONT][FONT=monospace][FONT=monospace]**/etc/sysconfig/packagekit-background and is slow at fixing bugs**
--- /usr/lib/systemd/system/packagekit-background.service       2021-05-28 03:35:40.000000000 +0200 
+++ /etc/systemd/system/packagekit-background.service   2020-10-29 21:29:49.384620843 +0100 
@@ -2,4 +2,4 @@ 
 Description=Script to update the system with PackageKit 
  
 [Service] 
-ExecStart=/usr/share/PackageKit/packagekit-background.sh 
+ExecStart=/usr/local/PackageKit/packagekit-background.sh 

**[OVERRIDDEN]** /etc/systemd/system/wpa_supplicant@.service → /usr/lib/systemd/system/wpa_supplicant@.service 
**# dbus version prone to cryptic error messages, not needed with systemd-networkd **
--- /usr/lib/systemd/system/wpa_supplicant@.service     2021-05-28 01:57:37.000000000 +0200 
+++ /etc/systemd/system/wpa_supplicant@.service 2021-05-03 06:27:24.821143076 +0200 
@@ -1,12 +1,10 @@ 
 [Unit] 
 Description=WPA Supplicant daemon (interface %i) 
-After=dbus.service network.target 
-Requires=sys-subsystem-net-devices-%I.device 
-After=sys-subsystem-net-devices-%I.device 
+Requires=sys-subsystem-net-devices-%i.device 
+After=sys-subsystem-net-devices-%i.device 
  
 [Service] 
-Type=dbus 
-BusName=fi.w1.wpa_supplicant1 
+Type=simple 
 ExecStart=/usr/sbin/wpa_supplicant -i%i -c /etc/wpa_supplicant/wpa_supplicant.conf -u -t -f /var/log/wpa_supplicant.log 
  
 [Install] 


2 overridden configuration files found. 
**3400G:~ #**[/FONT][/FONT]

BTW: Note the subtle difference. Upper case ‘%I’ works in vendor version but causes a fatal error in the site version.

**3400G:~ #** diff /usr/lib/systemd/system/wpa_supplicant@.service /etc/systemd/system/wpa_supplicant@.service    
3,5c3,4 
< After=dbus.service network.target 
< Requires=sys-subsystem-net-devices-**%I**.device 
< After=sys-subsystem-net-devices-**%I**.device 
--- 
> Requires=sys-subsystem-net-devices-**%i**.device 
> After=sys-subsystem-net-devices-**%i**.device 
8,9c7 
< Type=dbus 
< BusName=fi.w1.wpa_supplicant1 
--- 
> Type=simple 
**3400G:~ #**

Change is the only constant in maintenance. Bugs emerge and require changes, which become obsolete when fixing the bugs:

One bug resulted in unintended invocation of packagekit and caused me to temporarily mask some unit files: https://forums.opensuse.org/showthread.php/537260-How-To-Configure-PackageKit-Services
A user got affected by premature invocation of WPA Supplicant: https://forums.opensuse.org/showthread.php/547186-wpa_supplicant-service-fails-on-boot-succeeds-on-restart Discussing the problem in detail resulted in the following minimal version of the unit:

**3400G:~ #** systemctl cat wpa_supplicant@.service                                                                          
**# /etc/systemd/system/wpa_supplicant@.service**
[Unit] 
Description=WPA Supplicant daemon (interface %i) 
Requires=sys-subsystem-net-devices-%i.device 
After=sys-subsystem-net-devices-%i.device 

[Service] 
Type=simple 
ExecStart=/usr/sbin/wpa_supplicant -i%i -c /etc/wpa_supplicant/wpa_supplicant.conf -u -t -f /var/log/wpa_supplicant.log 

[Install] 
WantedBy=multi-user.target 
**3400G:~ #**

Summary: The unit gets installed by multi-user.target, waits for the net devices and runs wpa_supplicant with parameters specified in line ExecStart=… . Only definitions there which are really needed. No fancy lines which may cause errors in the future.

** With system administration discipline is mandatory.
**

rhussain · June 26, 2021, 5:07am

Hi,

I installed fresh copy of OpenSuse Leap 15.3. I tried to upgrade the system but I am seeing Update Error in system tray. Especially with security patches. I resolved this issue by following the this guide. Please click the following link
https://www.fossadventures.com/the-best-way-to-update-your-opensuse-leap-system/

Click on view after launching the Yast software management option
RIght click on AppStream > All in this list > Update if new version available
Please select the first radio button and follow the instruction and you are done.

Now I am not seeing any update error of security patches