Bug 1150790 - Unexpected behavior when installing Tumbleweed without recommended packages
Unexpected behavior when installing Tumbleweed without recommended packages
Status: RESOLVED FEATURE
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Patterns
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Dominique Leuenberger
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-14 20:31 UTC by Hagen Buliwyf
Modified: 2020-12-29 14:39 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hagen Buliwyf 2019-09-14 20:31:25 UTC
I installed openSUSE Tumbleweed20190824-0 with the option "Install recommended packages" disabled from the very beginning.

After the first reboot i was confronted with two unexpected behaviors

1.)
Instead of the expected graphical login screen i got a command line login prompt.

2.)
The user interface language was a mix of english and the language i had selected at install time (german).

I tried this on different hardware with identical results. One hardware configuration was:

Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 31,3 GiB
Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
Samsung SSD 850 PRO 256GB (pre-partitioned with GPT but otherwise empty)

How to reproduce:
=================

Boot the openSUSE Tumbleweed installation media and change the defaults of the installer as follows

Language + Keyboard Layout: select "German"
Network Settings: skip
System Role: select "Desktop with KDE Plasma"
Expert Partitioner - Start with existing Partitions => ESP (fat32), /(ext4), home(ext4)
Clock and TimeZone: make no changes
Local User: create a user with "Automatic Login" and "Use this password for system Administrator" both disabled
Authentification for System Administrator: provide a password
Installer Settings: select "Software"
Software Selection and System Tasks: select "Details..."
on next screen: select menu item "Dependencies" and disabled "Install recommended packages"
press "Accept" and you will be presented with a list of packages to be installed
pressing "OK" will bring you back to "Installer Settings"
press "Install"

On reboot you will be presented with a command line login prompt (althoug you selected "System Role: Desktop with KDE Plasma"). You will find that no display manager is installed.

Installing sddm will give you the expected graphical login and you can login a plasma session but the user interface will be a weird mix of english and german.

Going through yasts package list one by one you will discover that for many installed packages the correspondig -lang-package was not installed.

What i expected:
================

to get a graphical login screen on system startup
to have a desktop completely in the language i selected at install time.


I asked for help on opensuse-support@opensuse.org and there were basically two contrary opinions on this matter:

a)
All works as expected. My choice to disable the option "Install recommended packages" from the very beginning of the installation is supposed to result in a behavior as described above.

b)
The behavior described above should be reported here (because it is not the expected one?).

I don't know what the truth is.
Comment 1 Michal Filka 2019-10-01 09:41:25 UTC
I see two issues described here
1) no graphical UI installed even when asked for (System Role: select "Desktop with KDE Plasma")

2) when a display manager is installed manually the UI has broken translations
Comment 2 Michal Filka 2019-10-01 09:42:44 UTC
To look deeply into it we would need yast logs from installation. You can achieve them by save_y2logs (see https://en.opensuse.org/openSUSE:Report_a_YaST_bug).
Comment 3 Michal Filka 2019-10-01 09:45:16 UTC
@Martin:

Can issue (2) from the Comment#1 be caused by disabling "Install recommended packages"? Is it caused by e.g. separating translations for some packages into own dedicated rpms?
Comment 4 Hagen Buliwyf 2019-10-01 15:09:13 UTC
(In reply to Michal Filka from comment #1)
> I see two issues described here
> 1) no graphical UI installed even when asked for (System Role: select
> "Desktop with KDE Plasma")
> 
> 2) when a display manager is installed manually the UI has broken
> translations

Well, i would phrase that different:

If one decides on her/his way through the installation process to disable the option "Install recommended packages" then certain packages requested by earlier steps of the Installation process will not be installed (without any warning) e.g.:

many -lang-packages although in the very first step of the installation process a language not equal to "english" was selected

displaymanager although "Desktop with KDE plasma" was selected
Comment 5 Hagen Buliwyf 2019-10-01 15:14:07 UTC
(In reply to Michal Filka from comment #2)
> To look deeply into it we would need yast logs from installation. You can
> achieve them by save_y2logs (see
> https://en.opensuse.org/openSUSE:Report_a_YaST_bug).

In the meantime i finished setting up the systems and they are in production so i cannot provide any useful logfiles from the installation itself.

However the behavior can be easily reproduced.
Comment 6 Hagen Buliwyf 2019-10-01 15:27:39 UTC
(In reply to Michal Filka from comment #3)
> @Martin:
> 
> Can issue (2) from the Comment#1 be caused by disabling "Install recommended
> packages"? Is it caused by e.g. separating translations for some packages
> into own dedicated rpms?

Just for your information:

When i build the systems i first used "zypper in --no-recommends packagename" to install the additional packages i needed and found that some packages nevertheless pulled in their -lang-packages while others did not.

So i changed my approach and first checked with "zypper se packagename" whether a package has a language package or not. If there was a language package i used "zypper in --no-recommends packagename-lang" and that would always pull in packagename and packagename-lang.
Comment 7 Stefan Hundhammer 2019-12-03 11:16:13 UTC
I just talked to Michael Andres, our senior libzypp maintainer.

He said that those language specific packages should all have a "supplements" dependency which will be honored even if you choose to install without recommended packages.

Since you do get at least some translation packages, the mechanism works in principle. Still it is possible that some packages use the wrong mechanism, i.e. a "recommends" somewhere instead of "supplements" which is basically a reverse "recommends".

If you can tell us what packages are affected, we could go forward here (assigning the problem to the individual package maintainers). If not, I fear this will lead nowhere.

As for the missing display manager (i.e. only text mode login), we'd need y2logs.
Comment 8 Hagen Buliwyf 2019-12-03 15:17:42 UTC
(In reply to Stefan Hundhammer from comment #7)
> I just talked to Michael Andres, our senior libzypp maintainer.
> 
> He said that those language specific packages should all have a
> "supplements" dependency which will be honored even if you choose to install
> without recommended packages.
> 
> Since you do get at least some translation packages, the mechanism works in
> principle. Still it is possible that some packages use the wrong mechanism,
> i.e. a "recommends" somewhere instead of "supplements" which is basically a
> reverse "recommends".
> 
> If you can tell us what packages are affected, we could go forward here
> (assigning the problem to the individual package maintainers). If not, I
> fear this will lead nowhere.
> 
Is there a way to examine my -lang-packages whether they have the correct setup or not?

If not i would have to do a second installation. However because i'm aiming for a very limited set of packages chances would be high that i only would find very few of the faulty ones.

Isn't there a way (in OBS) to address all owners of -lang-packages or - even better - a way to check -lang-packages by script?

> As for the missing display manager (i.e. only text mode login), we'd need
> y2logs.

As i already said in my comment #5: i don't have access to that system any more but both problems (no desktop-manager installed, missing language packs) can be reproduced at any time as i described in my initial post.
Comment 9 Hagen Buliwyf 2019-12-03 15:27:47 UTC
Not SOLVED!

It is well known how to reproduce the problem. Any information needed for bug fixing can be easily generated at any time.
Comment 10 Dominique Leuenberger 2020-04-02 10:41:40 UTC
(In reply to Stefan Hundhammer from comment #7)
> Since you do get at least some translation packages, the mechanism works in
> principle. Still it is possible that some packages use the wrong mechanism,
> i.e. a "recommends" somewhere instead of "supplements" which is basically a
> reverse "recommends".
> 
> If you can tell us what packages are affected, we could go forward here
> (assigning the problem to the individual package maintainers). If not, I
> fear this will lead nowhere.

This nails it. We need bugs to be specific, on the point. Any such generalized meta-bug that could affect all or none (both is not true, as the information provided already shows) can't be handled.

Please observe your install behavior and try to report the issue with lang package on a specific package (one bug per issue - collection bugs will hardly ever reach any reasonable conclusion)
Comment 11 Hagen Buliwyf 2020-04-05 10:45:12 UTC
(In reply to Dominique Leuenberger from comment #10)
 
> Please observe your install behavior and try to report the issue with lang
> package on a specific package (one bug per issue - collection bugs will
> hardly ever reach any reasonable conclusion)

If a user selects as the very first option of an installation a language other than "American English" he should get all packages necessary to fulfill this request independent of any option chosen later on in the installation process. 

If this is not the case then something is definitely not working as expected.

To the plain user it is hard to tell where the problems origin is.

From my point of few there are four ways to tackle this problem:

1.)
Include a testcase in OpenQA to check this specific situation.

2.)
Change the installer so that it handles this situation correctly.

3.)
Find a way in OBS to deal with *-lang packages which do not behave correctly.

4.)
As you did- ask the users to file bugs for every not installed *-lang package.

The first three approaches will result in a future-proof soulution.

The last one ... well, it might help to solve the problem as well. However it will never provide a final solution to the problem. And if people (like me) will install with "--no-recommends" set then it will take years to finaly solve the problem.
Comment 12 Dominique Leuenberger 2020-12-29 14:39:56 UTC
option 4 is perfectly valid. This is a community distribution, you being part of the community can help to provide the needed information.