Bugzilla – Bug 1211869
Missing dependencies prevents launch of graphical Yast
Last modified: 2023-08-14 21:21:13 UTC
On Leap 15.3, desktop-data-openSUSE had a dependency on xdg-utils. On Leap 15.4 this is no longer the case. Someone setting up a minimal OS installation may have yast2-control-center installed, which provides the file "/usr/share/applications/org.opensuse.YaST.desktop". This file includes the line: Exec=/usr/bin/xdg-su -c /sbin/yast2 Therefore yast2-control-center (or perhaps desktop-data-openSUSE) should depend on utilities it uses, namely xdg-su (provided by xdg-utils). Without it YaST is missing from the Applications/System Tools menu.
You are right: That dependency somehow got lost. On my up-to-date Leap 15.4 installation with Xfce as a desktop, I get: % rpm -q --whatrequires xdg-utils simple-scan-3.34.2-1.82.x86_64 xfce4-dict-0.8.4-bp154.1.55.x86_64 menulibre-2.2.3-bp154.1.60.noarch gparted-1.3.1-bp154.1.79.x86_64 xsane-0.999-bp154.2.85.x86_64 pcmanfm-1.3.2-bp154.1.35.x86_64 gimp-2.10.30-150400.3.8.2.x86_64 kid3-qt-3.8.7-bp154.1.43.x86_64 chromium-ffmpeg-extra-103.0.5060.114-150400.2.pm.1.x86_64 chromium-112.0.5615.165-bp154.2.84.1.x86_64 None of those is guaranteed to be installed. I guess I got the xdg-utils package as part of some pattern.
But not having xdg-utils installed is bad news for almost all YaST modules: All except very few need root permissions, so their .desktop files in /usr/share/applications/YaST2 use an "xdg-su" command line. And every single one of them belongs to the package of the YaST module they start, so adding those dependencies manually everywhere would mean touching every YaST package that comes with one or more .desktop file(s).
> would mean touching every YaST package Yes, every package that uses xdg-su should have a dependency on xdg-utils. Unless/until there's a way for this to be automatically detected, manually adding "Requires: xdg-utils" to a collection of RPM .spec files seems appropriate.
And indeed, this was much simpler in Leap 15.3: balrog-leap-15-3:~ # cat /etc/os-release NAME="openSUSE Leap" VERSION="15.3" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="15.3" PRETTY_NAME="openSUSE Leap 15.3" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:15.3" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" balrog-leap-15-3:~ # rpm -q --whatrequires xdg-utils desktop-data-openSUSE-15.0.20171024-lp153.1.53.noarch
I have "just" 65 yast2-* packages installed on my Leap 15.4. I don't remember exactly how many YaST packages / source repositories there are; it must be 100+. I don't think we are going to do that kind of busywork change on every one of them. This needs to be fixed at some central point. I don't know why this was moved out from that desktop-data-openSUSE package to become a burden of all the individual packages. Let's try to find out.
> I don't remember exactly how many YaST packages / source repositories there are; it must be 100+ Fair enough. The problem is understood, I'll trust you to find an appropriate solution. Thanks.
[sh @ balrog] ~ 5 % osc maintainer -e desktop-data-openSUSE Defined in package: X11:common:Factory/desktop-data-openSUSE bugowner of desktop-data-openSUSE : - maintainer of desktop-data-openSUSE : hel@lcp.world Defined in project: X11:common:Factory bugowner of desktop-data-openSUSE : dmueller@suse.com maintainer of desktop-data-openSUSE : dmueller@suse.com, ke@suse.com, mkudlvasr@novell.com, mseben@gmail.com, simonf.lees@suse.com, - Defined in project: X11:common bugowner of desktop-data-openSUSE : - maintainer of desktop-data-openSUSE : dmueller@suse.com, maw@pobox.com Defined in project: X11 bugowner of desktop-data-openSUSE : - maintainer of desktop-data-openSUSE : sndirsch@suse.com Unfortunately no hint in the .changes file: https://build.opensuse.org/package/view_file/X11:common:Factory/desktop-data-openSUSE/desktop-data-openSUSE.changes?expand=1
Stasiek, do you know when and why this was changed? What was the rationale behind it? I also don't remember anybody contacting the YaST team about it.
Essentially the reason was that we removed the need for desktop-data-openSUSE to itself depend on any xdg utility. Any application that depends on xdg tooling should include the dependency by itself, it would be nice to have a test in rpmlint or something that checks whether or not the package itself or its direct dependency includes the binary it's using in its desktop files, to avoid issues like that.
For the record: xdg-utils do not have a dependency on any X11 lib, just on Perl and some few Perl modules. [sh @ balrog] ~ 10 % rpm -q --requires xdg-utils /bin/sh perl perl-Net-DBus perl-X11-Protocol rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 which xdg-su is a shell script that checks environment variables what desktop is in use, and depending on the result, it uses one of - kdesu - gnomesu - lxqt-sudo or starts "xterm" with a "su -c" command (!).
Since it would be total overkill to change all those YaST modules, AFAICS adding a dependency to a central package like yast2-control-center-qt sounds like a good compromise.
Notice that this might not fix every pathological situation like using a simple window manager, not a full-fledged desktop, and deliberately not installing yast2-control-center-qt. But so be it.
> adding a dependency to a central package like yast2-control-center-qt sounds like a good compromise That works for me and will fix the issue for the collection of packages I use. Thanks.
Fix: https://github.com/yast/yast-control-center/pull/54 (Factory / TW)
SR to OBS / Factory: https://build.opensuse.org/request/show/1090200
I just received the new yast2-control-center-qt-4.6.1 package via the YaST:Head repository (https://download.opensuse.org/repositories/YaST:Head/openSUSE_Leap_15.4) on my Leap 15.4, I now get: % rpm -q --whatrequires xdg-utils simple-scan-3.34.2-1.82.x86_64 xfce4-dict-0.8.4-bp154.1.55.x86_64 menulibre-2.2.3-bp154.1.60.noarch gparted-1.3.1-bp154.1.79.x86_64 xsane-0.999-bp154.2.85.x86_64 pcmanfm-1.3.2-bp154.1.35.x86_64 gimp-2.10.30-150400.3.8.2.x86_64 kid3-qt-3.8.7-bp154.1.43.x86_64 chromium-ffmpeg-extra-103.0.5060.114-150400.2.pm.1.x86_64 chromium-113.0.5672.126-bp154.2.87.1.x86_64 yast2-control-center-qt-4.6.1-lp154.1.1.x86_64 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With SR 1090200 accepted into factory, what else needs to happen to get the fix into Leap 15.4? Incidentally, 15.4 currently provides yast2-control-center 4.4.3-150400.1.10. Will the fix be backported or will Leap jump up to 4.6.1-lp154.1.1 from factory?
No, there will not be a backport to 15.4. This is a very rare exceptional case. Anybody who has a need for this can easily install that one package manually.
(In reply to Stefan Hundhammer from comment #18) > No, there will not be a backport to 15.4. This is a very rare exceptional > case. Anybody who has a need for this can easily install that one package > manually. Thanks for the clarification. I'll stick with yast2-control-center 4.4.3-150400.1.10 from the official Leap repo (in case there are security updates), but explicitly include xdg-utils on my system to compensate for the missing dependency. It's a shame that it won't be fixed in Leap 15.4, but at least factory has the fix so future releases and Tumbleweed may benefit.
Backporting this would be an exercise in futility. Those few users who have this problem (i.e., those who do not use any of the standard desktops like KDE Plasma, GNOME, Xfce, LXDE, LXQt, the patterns of which should all contain the xdg-utils package) already realized about one year ago that starting a YaST module from the YaST Qt control center or from the menu of their window manager or desktop does not work. Yet we never saw any complaints from any of them before this bug, so this can't be a very common scenario.