|
Bugzilla – Full Text Bug Listing |
| Summary: | Removing one yast module unselects installation of libyui-qt7 (resulting in a text-only yast on GUI setup) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Per Jessen <per> |
| Component: | YaST2 | Assignee: | Ludwig Nussel <lnussel> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dimstar, lnussel, lslezak, mvidner, shundhammer, simonf.lees |
| Version: | Leap 42.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
ps axfl output
zypper lr --url y2logs yast libyiu selection before I deselect yast2-firewall yast libyui selection after I deselect yast2-firewall Resolver test case |
||
the scariest part I see is that it wants to start yast ncurses mode (not qt mode) of course this should still not hang though as for ncurses/qt: is this intentional by you? do you have libyui-qt7 installed? (In reply to Dominique Leuenberger from comment #1) > the scariest part I see is that it wants to start yast ncurses mode (not qt > mode) > > of course this should still not hang though > > as for ncurses/qt: is this intentional by you? do you have libyui-qt7 > installed? # rpm -qa | grep libyui libyui-ncurses7-2.47.4-1.2.x86_64 libyui-ncurses-pkg7-2.48.2-1.1.x86_64 libyui7-3.2.3-1.2.x86_64 It's the default install of Leap with KDE. 'default'? no way: curl https://openqa.opensuse.org/tests/95869/file/info.txt | grep libyui % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0libyui-qt-graph7-2.44.5-1.1.x86_64 libyui7-3.2.3-1.1.x86_64 libyui-qt7-2.46.21-1.1.x86_64 libyui-ncurses-pkg7-2.48.2-1.1.x86_64 libyui-ncurses7-2.47.4-1.1.x86_64 libyui-qt-pkg7-2.45.5-1.2.x86_64 100 102k 100 102k 0 0 286k 0 --:--:-- --:--:-- --:--:-- 286k dimstar@zeus:~/Documents/osc/openSUSE:Leap:42.1/plymouth> How did you install this system? * Updates or fresh install * If update: zypper dup or boot from DVD or [think of other ways you could have done it] * If from Media: Which build ID did you use? (not that I know of any build that had a default KDE with a broken yast setup) Anyway: please also attach the yast log files https://en.opensuse.org/openSUSE:Bugreport_YaST#I_reported_a_YaST2_bug.2C_and_now_I_am_asked_to_.22attach_y2logs.22_.28for_package_installation_also_.22libzypp_logging.22.29._What_does_that_mean.2C_and_how_do_I_do_that.3F (In reply to Dominique Leuenberger from comment #3) > 'default'? no way: > Hmm, I think the only changes I made were - install nvidia driver - don't install grub Looking the repos now, I don't see the -Current though, see attachment. > > How did you install this system? > * Updates or fresh install Fresh, about a week ago. From 42.1-current. > * If from Media: Which build ID did you use? (not that I know of any build > that had a default KDE with a broken yast setup) It is a network install, pxe+ssh+http from http://download.opensuse.org/distribution/leap/42.1-Current/repo/oss > Anyway: please also attach the yast log files If you think the system got screwed up somehow, it's easier to just do another installation, it's only for testing. Created attachment 653359 [details]
zypper lr --url
Created attachment 653360 [details]
y2logs
(In reply to Per Jessen from comment #4) > > > > How did you install this system? > > * Updates or fresh install > > Fresh, about a week ago. From 42.1-current. Correction, 17/10/2015, so 10 days ago. Let's ignore this, I'll do a fresh install and see if that improves. Okay, something is weird. I have just started a new installation (-current). I do the following minor changes: change the bootloader to none deselect grub2, susefirewall and yast2-firewall. add knode, lilo and wireshark When I deselect yast2-firewall, the libyiu* selection changes dramatically, see attached. Created attachment 653369 [details]
yast libyiu selection before I deselect yast2-firewall
Created attachment 653371 [details]
yast libyui selection after I deselect yast2-firewall
module yast2-printer is also automatically deselected.
(In reply to Per Jessen from comment #8) > When I deselect yast2-firewall, the libyiu* selection changes dramatically, > see attached. Passing on to the YaST team... something is messing up. One thing I just noted: > rpm -q --recommends yast2-control-center-qt libyui-qt5 That is not being kept in sync with reality (In reply to Per Jessen from comment #8) > When I deselect yast2-firewall, the libyiu* selection changes dramatically, > see attached. Dramatically = libyui-qt7, libyui-qt-graph7 and libyui-pkg7 are being deselected. HuHa, as Martin is sick and there is a public holiday in the play as well, would you mind checking this? BTW, I guess that starting Yast in ncurses has been already fixed, but now it's about libyui7 vs 5 and firewall and control center (?). I guess red-herring is somewhere in the loop too :) Looks like two (or more) issue in one bug(report) BTW. (In reply to Lukas Ocilka from comment #13) > HuHa, as Martin is sick and there is a public holiday in the play as well, > would you mind checking this? BTW, I guess that starting Yast in ncurses > has been already fixed, but now it's about libyui7 vs 5 and firewall and > control center (?). I guess red-herring is somewhere in the loop too :) > Looks like two (or more) issue in one bug(report) BTW. My bad - I side tracked this bug... I'd indeed say we keep this one for the 'installer over ambitious removes libyui-qt7' - which is more or less the 'root' for the evil in this bug. for control-center recommending some other lib I'll file a bug on its own (lower prio) Sorry, I saw this too late - just a couple of minutes ago. So the issue is why libyui7 gets uninstalled in favour of libyui5 -- or libyui-qt7 vs. libyui-qt5 ? We'll have to do another test installation and then try to set the older version (-5) to "taboo" and wait for the dependency problem dialog; it might tell us (hopefully) why libzypp wants to keep the -5 version. It's hard to tell without trying. OK, I can reproduce it with Leap GM in a QEMU installation: - start installation - leave defaults and click "Next" until the proposal dialog - Unselect "firewall" there - Change bootloader proposal to "No bootloader" - Go to detailed software selection -> libyui-qt7, libyui-qt-pkg7, libyui-qt-graph7 are selected - unselect - Grub2 - SuSEfirewall2 - yast2-firewall -> libyui-qt7, libyui-qt-pkg7, libyui-qt-graph7 are no longer selected. It does not happen in SLE-12 SP1 because there SuSEfirewall2 is required by the "base" pattern, i.e. you can't easily unselect it there (other than confirming to either break or unselect that "base" pattern which will put the responsibility on the user's shoulders). As Dominique already found out in comment#11, one problem seems to be that the yast2-control-center-qt recommends the old libyui-qt5, but the latest version is libyui-qt7. From a solver test case I triggered in that installation scenario: <package> <name>yast2-control-center-qt</name> ... <recommends> <dep name='libyui-qt5' /> </recommends> ... </package> Created attachment 654619 [details]
Resolver test case
Ludwig Nussel helped me to track this down:
This appears to be a bug in the underlying software patterns.
The yast-qt-ui (libyui-qt7, libyui-qt-pkg7, libyui-qt-graph7) are installed from one of the patterns patterns-openSUSE-kde_yast (via pattern kde_yast) or
patterns-openSUSE-gnome_yast (via pattern kde_yast).
patterns-openSUSE-kde_yast is installed if both patterns-openSUSE-kde and patterns-openSUSE-yast2_basis are installed (and in other combinations that each include patterns-openSUSE-yast2_basis).
patterns-openSUSE-yast2_basis, however, requires a number of YaST modules, including (among others) yast2-firewall:
<package>
<name>patterns-openSUSE-yast2_basis</name>
...
<requires>
<dep name='yast2' />
<dep name='yast2-packager' />
<dep name='yast2-installation' />
<dep name='yast2-network' />
<dep name='yast2-pkg-bindings' />
<dep name='yast2-storage' />
<dep name='yast2-perl-bindings' />
<dep name='yast2-country' />
<dep name='yast2-ldap' />
<dep name='yast2-users' />
<dep name='yast2-pam' />
<dep name='yast2-transfer' />
<dep name='yast2-update' />
<dep name='yast2-xml' />
<dep name='yast2-online-update' />
<dep name='yast2-security' />
<dep name='libyui-ncurses-pkg' />
<dep name='yast2-firewall' />
<dep name='yast2-hardware-detection' />
<dep name='yast2-services-manager' />
<dep name='yast2-sysconfig' />
<dep name='yast2-tune' />
<dep name='yast2-mail' />
<dep name='yast2-online-update-frontend' />
<dep name='yast2-theme-openSUSE' />
<dep name='rpmlib...
</requires>
It also recommends a number of other YaST modules:
<recommends>
<dep name='yast2-inetd' />
<dep name='yast2-nis-client' />
<dep name='yast2-ntp-client' />
<dep name='yast2-samba-client' />
<dep name='yast2-slp' />
<dep name='yast2-auth-client' />
<dep name='yast2-kerberos-client' />
<dep name='yast2-ldap-client' />
<dep name='yast2-nfs-client' />
<dep name='yast2-printer' />
<dep name='yast2-samba-server' />
<dep name='yast2-vm' />
<dep name='yast2-fonts' />
<dep name='yast2-iscsi-client' />
<dep name='yast2-journal' />
<dep name='yast2-metapackage-handler' />
<dep name='yast2-sudo' />
<dep name='yast2-packager-webpin' />
<dep name='yast2-vpn' />
</recommends>
If any of those required packages is missing, the pattern is not fulfilled (i.e. it counts as "not installed"), so the condition to install patterns-openSUSE-kde_yast or patterns-openSUSE-gnome_yast is not fulfilled, so the yast-qt-ui does not get installed.
Trying to install without yast2-network or yast2-ldap (!) has the same effect as deselecting yast2-firewall: The yast2_basis pattern is not fulfilled -> no yast-qt-ui. Since we don't want to force the yast-qt-ui on every user installing KDE, GNOME or any other X11 desktop, we need to do this on the patterns level. One approach might be to be less strict with the required yast2 packages in the yast2_basis pattern and include only the plain yast2 package there (which is required by most (all?) other yast modules anyway, so there would be no harm done) and move all the others to the 'recommends' block. Reassigning to Coolo to make a decision and change the patterns accordingly. and then users installing "without recommends" will not get any yast module - even if installing the yast pattern? Description : YaST tools for basic system administration. (In reply to Stephan Kulow from comment #21) > and then users installing "without recommends" will not get any yast module > - even if installing the yast pattern? > > Description : > YaST tools for basic system administration. There are other bug reports here where its documented that patterns will not work without recommends turned on, if we want them too there are other areas that may need fixing as well. This is automated batch bugzilla cleanup. The openSUSE 42.1 changed to end-of-life (EOL [1]) status. As such it is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of openSUSE, or you can still observe it under openSUSE Leap 15.0, please feel free to reopen this bug against that version (see the "Version" component in the bug fields), or alternatively open a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime |
Created attachment 653336 [details] ps axfl output I very rarely have reason to do this, but when I tried today, it didnt work: start YaST from the KDE start menu System->YaST. It just hangs.