Bugzilla – Bug 797304
yast2-packager: Don't install recommended packages for minimal pattern
Last modified: 2015-06-25 09:10:44 UTC
Created attachment 519347 [details]
potential patch, untested
The minimal pattern suffers from size problems due to packages recommending lots of others that are considered unneeded for a minimal installation. There is no way for a pattern to express that recommended packages should be ignored. So far the only way to block such packages it to have a pattern that conflicts with them which is not ideal either.
So as a hack yast could be patched to not install recommended packages during initial installation with the minimal pattern.
Some clarification after talking to Gabi. Of course this is also just a hack but I see no good solution either. Some kind of "soft conflict" would be nice or a way to ignore only certain dependencies like it's possible in obs. We don't have that though.
Also, this change comes at a price. The minimal pattern has to require packages then, atm it only recommends stuff too.
I wouldn't change the current behaviour and set the solver flag 'onlyRequires' to 'true' generally for the minimal server selection. There might be also users who don't want it this way and I think the "recommends" of packages usually make sense. And as Ludwig wrote, the minimal selection has to require packages then.
Users who want to reduce the number of packages installed can customize the
selection by entering 'Software' in 'Installation Settings' overview.
For Qt: click 'Details' and select 'View' 'Installation Summary'. Tab 'Package'
has an entry to change status for all packages in the list (to 'Do not
install') and with it only the required packages remain automatically selected.
For ncurses: Select 'Package Classification' from 'Filter' menu and
'Recommended' packages. There is also the possibility to change status of all
packages in the list ('Actions', 'All listed packages', 'Keep All').
Remark to the patch: AFAICS the value for desktop is "textmode" and the solver flag has to be set always according to the selected desktop (in case of reentering the desktop selection).
Ludwig, do you agree to let yast2-packager unchanged? I think the possibility to customize the package selection is a good solution for now.
To deselect all recommended packages is not a good idea because also 'grub' and 'grub2' are deselected then. Shouldn't they be required?
What's the point of having patterns if you argue that you could always tune the installation manually? That misses the point, sorry.
Making sure the correct boot loader package is installed is the duty of yast2-bootloader.
Assigning to the maintainer of yast2-packager.
now that 12.3 is done and we have plenty time to test this change on the road to 13.1 could you please apply the patch now?
for me as a user, the current situation with the minimal_conflicts pattern is really off-putting. i absolutely don't expect a "minimal" installation hampering future attempts to install further software. other GNU/Linux distro and other operating system i've used install whatever they consider "minimal" and then let me install more stuff.
"minimal" says "you can't live without this, and you don't need anything else" in English while in Susish, "you can't live without this" is apparently spelled "recommended". it's absurd.
This is also related to https://fate.suse.com/318099 'Possibility to install with "no recommends"' which I am working on. I have added a Use Case (UC5) for this bug to that Fate entry.
I haven't known about the minimal_base-conflicts pattern
(search in https://build.opensuse.org/package/view_file/openSUSE:Factory/patterns-openSUSE/patterns-openSUSE.spec?expand=1 )
In the control file it does not have an associated bug: https://github.com/yast/skelcd-control-openSUSE/commit/611726e183a14177a04dc4c446761f06f5a30d6f
I thought the solution would be to disable the Recommended solver flag for the installation based on the desktop chosen, like Ludwig proposed in comment 0.
Coolo, would the "conflict" pattern be still necessary then?
Unfortunately disabling recommends also disables hardware supplements AFAIK which might be an undesirable side effect on physical hardware. So hardware supplements may handling may need to be decoupled from no-recommends in the solver first.
Then this would eliminate the need for the minimal-conflicts pattern, yes.
An alternative I though of might be to somehow allow a pattern to provide a list of soft-locks. So I can selectively soft-lock certain packages.