Bugzilla – Bug 114072
yast2 forgets custom package selection during the installation
Last modified: 2005-09-09 14:47:36 UTC
steps to reproduce: 1. booted from DVD 2. select SLP install 3. select as install source 10.0 beta3 -> http://10.10.0.100/install/SUSE-10.0-DVD-Beta3/CD1/ 4. choose a base selektion. which doesnt matter. i reproduced it with "minimal graphical" selection and kde. 5. choose "software" on the next dialog 6. remove/add some packages 7. choose Accept 8. although in the package selection the correct size and package count was shown. the overview now shows the value for the original base selection. 9. selecting "software" again. the package manager really is at the state of the base selection. i will attach the logs of both installations: - logs1.tar.bz2 minimal selected as base -> modified and fully installed I just wondered why it forgot some packages and dumped that installation directly. - logs2.tar.bz2 started as minimal too. as the above cycle has shown the bug again. i tried it with the kde selection. all customizations got lost too so i decided to install a kde selection to get a working system. - user.sel after i modified the kde selection i saved the user.sel to see how it looks like. I even tried to load it into yast2 in the installed system. Wasnt a good idea actually as it tried to uninstall nearly everything of the base system.
The base selection is somehow reset between 11:28:37 and 11:45:46 from the first installation. Michael, any idea which builtin reset the base selection?
The base selection is from some reason reset. Unfortunatelly, I was not able to find the reason from the logs, nor reproduce the problem. Could you, please, test it with Beta4 when it is out and if the problem still occurres, try to reproduce with Y2DEBUG=1 (append it to kernel command line) and grab the logs as soon as the packages are reset?
i will try to reproduce it again
Any results? So far, I haven't reproduced it and I haven't got any similar report.
sorry but it seems i forgot one step in my "steps to reproduce". after going to the package selection i set the "graphical base system selection" to taboo and tell yast in the next dialog that i want to remove the "minimal+x11" selection. than i reselect the packages i want from "graphical base" and press Accept -> woops i am set back to minimal graphical system summarized steps to reproduce: 1. start a new installation 2. select some base selection (minimal graphical system e.g., breaks with KDE/ gnome too) 3. deselect "graphical base system" and tell yast in the next dialog to remove the referring selection 4. select all packges you actually want. 5. accept yast forgot all manually selected packages and is back to the selection you selected in step 2.
i have shown the steps to reproduce to AJ. down to major.
Thanks for this comment. The problem is that the referring selection is the base selecection - in this case "default". There must be always exactly one base selection selected. As you deselected it, during the proposal run, it was detected and the base selection was set again - which caused losing all the information about selected packages. Normally, this situation occurres only once - when the proposal is entered the first time. So, there are (technically) 2 possible solutions: 1. Remember that solution was already set and if user removes it, then don't set it again 2. Forbid to deselect the base selection in the package selector. I vote for 2, a base selection should always be installed IMO. Stefan, what do you think? Andreas, as this has just been lowered to Major and it is really rare situation, I suggest postponing the fix for 10.0++.
Uh - you can't change the base selection in the package selector - for exactly this reason. For the Qt package selector I am 100% sure, for the NCurses version 95%. The only way to change the base selection is the dialog right before the package selector, and IIRC this one will give you a stern warning if you have a custom selection.
Stefan, he changed the base selection. I would say 2 - or postpone for 10.1.
Yes, you really can, reproduced it here, just follow comment 8. Stefan, reassigning the bug to you to forbid it in the package selector (now or later).
Those base selections should not be visible in the package selector - this is the bug. Currently they are, and so the user can change them, thus resetting the package manager - without warning. I don't quite understand _why_ they are visible - the package selector explicitly only displays selections that are marked as "visible" and that are not base selections. From YQPkgSelList.cc: void YQPkgSelList::fillList() { clear(); y2debug( "Filling selection list" ); PMManager::PMSelectableVec::const_iterator it = Y2PM::selectionManager().begin(); while ( it != Y2PM::selectionManager().end() ) { PMSelectionPtr sel = ( *it)->theObject(); if ( sel ) { if ( sel->visible() && ! sel->isBase() ) { addPkgSelItem( sel ); } } ++it; } }
They are not visible in the selection selector. They are visible in the popup asking "how to resolve this dependecy conflict". And there, you can choose to deselect the base selection.
I just saw that. Disregard comment #14: Base selections are not visible in the selections list. What happens is that he set a selection to "taboo" ("graphical base system") that is required by the current base selection ("minimal + X11"). After dependency resolving, the dependency problem popup offers to delete dependent selections - in this case, the base selection. This of course may not happen. -> Trying to modify the dependency problem dialog so base selections are _not_ offered for deletion. Downgrading severity: This is a very academic case; this problem exists since SL 8.1 and nobody found it so far.
Now no longer offering the user to delete the base selection.