Bug 704123

(In reply to comment #0)
> 2. Either go to package menu and select all packages - update if newer version
> is available, or search for e.g. libeigen2. Look at Versions tab for
> libeigen2-devel.

Thomas: How does th UI implement this?

(In reply to comment #1)
> Thomas: How does th UI implement this?

The UI sets the item's status to S_Update if item->candidateIsNewer() && item->status() != S_Protected .

See YQPkgObjList::setAllItemStatus( ZyppStatus newStatus, bool force ) in http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgObjList.cc and YQPkgList::globalSetPkgStatus( ZyppStatus newStatus, bool force, bool countOnly ) in http://svn.opensuse.org/svn/yast/trunk/qt-pkg/src/YQPkgList.cc .

Hi, I also noticed the same thing.

Example situation today:

Currently installed: timidity 2.13.2-266.1-x86_64 vendor openSUSE
Available update: timidity 2.13.2-266.1-x64_46 vendor openSUSE-Education
Available update: timidity 2.13.2-266.1-x64_46 vendor obs://build........

All repositories at default priority (99).

When I click "All packages --> Update if newer version available", the version from BuildService is selected, with vendor change. Option "Allow vendor change" is unchecked in YaST and untouched in zypp.conf.

When running "zypper list-updates" the same update is also selected so it appears to be a zypper problem.

Other situation:

Currently installed: frozen-bubble 2.2.0-11.1-x86_64 vendor openSUSE
Available update repo#1 frozen-bubble 2.2.0-26.1-x86_64 vendor obs://build....
Available update repo#2 frozen-bubble 2.2.0-26.1-x86_64 vendor obs://build....

In this case, the same update package (wrong vendor, but twice the SAME vendor) is available from two different repositories. Neither YaST nor zypper propose the update, so the problem seems to arise specifically when an update is available from two distinct (wrong) VENDORS.

Hope this helps, greetings to all three.

@Haro: COuls you please attach a solver testcase (see http://en.opensuse.org/openSUSE:Bugreport_YaST#I_want_to_report_a_bug_related_to_package_dependencies_and_libzypp_solver_and_now_I_am_asked_to_.22attach_a_solver_testcase.22._Which_logs_to_attach.3F)

s/COuls/Could/

Created attachment 481608 [details]
Part 1 of Solver testcase from YaST menu Extras/Generate_Dependency_Resolver_Test_Case

Now that's a good deal of information you are collecting about my system...

Anyway, the bug currently affects libcurl4 (which I would like to have replaced by version 7.23.1-64.1-x86_64 from http://download.opensuse.org/repositories/devel:/libraries:/c_c++/openSUSE_11.4/ with priority 94 rather than http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_11.4/ with priority 96, but the radio button changes to the latter on the versions tab when I leave that package and return to it), libproj0 (which will be updated to 4.8.0-19.1-x86_64 from http://download.opensuse.org/repositories/home:/beyerle:/IAC/openSUSE_11.4/ rather than http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.4/ where the current version comes from, both with priority 98), and python-configobj (which will be updated to 4.7.2-24.1-noarch from http://download.opensuse.org/repositories/home:/beyerle:/IAC/openSUSE_11.4/ with priority 98 rather than http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_11.4/ with priority 96, again the latter being the source of the currently installed version).

Note that the vendor information for the libcurl4 version that always gets automatically selected mentions the obs://... address of the repo actually intended, but that does not match the repo name (unlike the other cases where it matches the repo name)!

In addition, I am currently experiencing a strange behaviour regarding package libenca0 which is installed from the base OSS repo with priority 99. YaST keeps trying to replace it with version 1.13-19.1-x86_64 from http://download.opensuse.org/repositories/Education/openSUSE_11.4/ with priority 100, and that same version is also available from http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_11.4/ with priority 96 (for which the vendor name openSUSE-Education is given, again not matching the repo name).

Created attachment 481609 [details]
Part 2 of Solver testcase from YaST menu Extras/Generate_Dependency_Resolver_Test_Case

Created attachment 481610 [details]
Part 3 of Solver testcase from YaST menu Extras/Generate_Dependency_Resolver_Test_Case

Last of the three parts, generated using
  split -b 10000000 y2logs.tgz y2logs.tgz.
because of size limit of bugzilla.

Need to be concatenated to be usable for tar.

> Now that's a good deal of information you are collecting about my system...

Looks like facebook. As I posted the link, I had the 'zypper in --debug-solver nopackage' output in mind. That's all I need (but it's included). Did not know that YaSt is that greedy.

(In reply to comment #3)
> Currently installed: timidity 2.13.2-266.1-x86_64 vendor openSUSE
> Available update: timidity 2.13.2-266.1-x64_46 vendor openSUSE-Education
> Available update: timidity 2.13.2-266.1-x64_46 vendor obs://build........
> 
> When I click "All packages --> Update if newer version available", the version
> from BuildService is selected, with vendor change. 

UI chooses wrong. 

obs:// version would be a vendor change. Note that 'openSUSE-Education' would be fine (that's probably what zypper has chosen). 
'openSUSE' and 'openSUSE-Education' are per default treated as being equivalent.


> Other situation:
> 
> Currently installed: frozen-bubble 2.2.0-11.1-x86_64 vendor openSUSE
> Available update repo#1 frozen-bubble 2.2.0-26.1-x86_64 vendor obs://build....
> Available update repo#2 frozen-bubble 2.2.0-26.1-x86_64 vendor obs://build....
> 
> In this case, the same update package (wrong vendor, but twice the SAME vendor)
> is available from two different repositories. Neither YaST nor zypper propose
> the update

Which is right.

(In reply to comment #6)

After checking the testcase and a glimpse into the YUI code Thomas mentioned in comment#2, I'm quite convinced that this is a ui issue, no problem in repos, zypp or solver.

(@Thomas: Maybe we can talk about this on Monday.)


> In addition, I am currently experiencing a strange behaviour regarding package
> libenca0 which is installed from the base OSS repo with priority 99. YaST keeps
> trying to replace it with version 1.13-19.1-x86_64 from
> http://download.opensuse.org/repositories/Education/openSUSE_11.4/ with
> priority 100, and that same version is also available from
> http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_11.4/ with
> priority 96 (for which the vendor name openSUSE-Education is given, again not
> matching the repo name).

Something that confused me in the testcase as well, but I checked the repo and it seems to be ok. multimedia:libs actually contains a few packages from Education.

Note that this is the reason for checking for a vendor-change and not for a repo-change. The vendor is immutable inside the rpm package header. openSUSE-Education packages may be updated by openSUSE-Education packages, no matter what kind of repository is used to provide them on you system.

@Thomas: I sent some more info per mail. IMO the UI should roughly selecht this way:


	Selectable sel;
	...

	if ( sel->status()!= S_Protected && sel->updateCandidateObj())
	{
	  if ( ! sel->setOnSystem( sel->updateCandidateObj(), USER(?) ) )
  		// actually this should not fail if you select by USER.
                // If you select by APPL_* this case woud indicate that
                // the user has already chosen a different candidate
                // for install
	  else
		// selected for install
	}
	else
	{
		// best object already installed OR package is locked
	}

> @Thomas: I sent some more info per mail. IMO the UI should roughly selecht this
> way:
> 
Michael, thank you for your support.

This bug is fixed in yast2-qt-pkg version 2.21.22.

This is an autogenerated message for OBS integration:
This bug (704123) was mentioned in
https://build.opensuse.org/request/show/111405 Factory / yast2-ncurses-pkg