Bugzilla – Bug 165832
Yast switch from "update" to "new install" broken
Last modified: 2006-04-18 21:14:42 UTC
I tried to update a system. The resolver showed several problems, some packages whcih should be updated/deleted/etc. So I decided to go back to the screen where "new installation" is offered for selection. After selecting "new installation", yast showed an error message in the Packages section, that dependencies cannot be solved. 1 Package selected for installation, total size 350 kB. After entering the Package selection I got a dependency problem of grub. All packages (beside wine and a hand full of other) were deselected. The selections were however "enabled"/selected. After talking to Klaus, it looks like Yast does not reset/empty his settings (package dependency calculations, whatever) when switching from the update mode to the new install mode with the back button. As we offer this possibility to our customers, it should be functional. I agree it's maybe not the usual way to do the job. Unfortunately it was not tested until now.
Created attachment 78212 [details] yast2 logs
From the description it sounds as if the pool isn't completely resetted (setTransact( false, ResStatus::USER ) for all pool items)
Michael, we might need such a function in ZYpp::
In ZYpp::? If this is what pkg-bindings want to do, thay can do it: ========================================================================= { for (zypp::ResPool::const_iterator it = zypp_ptr()->pool().begin() ; it != zypp_ptr()->pool().end() ; ++it) { it->status().setTransactValue( zypp::ResStatus::KEEP_STATE, zypp::ResStatus::USER) ; } } ========================================================================= If you like, zypp can provide a common SetTransactValue functor: struct SetTransactValue { SetTransactValue( ResStatus::TransactValue newVal_r, ResStatus::TransactByValue causer_r ) : _newVal( newVal_r ) , _causer( causer_r ) {} ResStatus::TransactValue _newVal; ResStatus::TransactByValue _causer; bool operator()( const PoolItem & pi ) const { return pi.status().setTransactValue( _newVal, _causer ); } }; So the pkg-bindings code could be reduced to { std::for_each( pool.begin(), pool.end(), SetTransactValue( ResStatus::TRANSACT, ResStatus::USER ) ); }
Huh ? KEEP_STATE and TRANSACT ? The above comment totally confuses me. Comment #2 was about _resetting_ all transactions
In fact, we need to clean up the pool as well to remove target resolvables etc. This will be tricky.
guys, if the fix is too intrusive/complex/whatever... would it be maybe better to disable the way back ? Once update selected, no way back to "new install" ??? We don't want to introduce now more problems. just my 2 cents
To disable it is probably the only way to go for box. I talked to Thorsten, it is OK with him also for SLES10 provided adding an add-on product will still be accessible even when user reaches installation proposal. The problem most probably also occurres if user selects different system for upgrade from the update proposal.
So, the steps I will do: - disable going back to installation mode dialog - disable going back to update partition selection dialog - remove update partition selection from update proposal These steps still allow to go back to add-on product dialog provided it was set to install add-on products together with the base product in the installatio mode dialog.
In addition to above steps, I added add-on products to installation and upgrade proposals (only for SLES and SLED). Done in SVN, resolving as FIXED.
*** Bug 158619 has been marked as a duplicate of this bug. ***