Bugzilla – Bug 426607
"zypper dup" wants to (needlessly?) reinstall lots of packages
Last modified: 2009-02-17 11:32:37 UTC
zypper dup wants to upgrade / downgrade a few packages, and additionally reinstall lots of packages, even though there is no need for that. (I brought the whole system to latest level by "yast2 sw_single", then "installation summary", "show kept packages", "update all where a newer version is available", so it should already be pretty up to date. Will attach the stdout of zypper.
Created attachment 239829 [details] stdout of "zypper dup"
Yes, this is really needlessly. Can you attach also a solver testcase? (rerun with --debug-solver option).
If the packages are different then they'll get reinstalled. Not a bug IMHO.
Created attachment 239851 [details] solver test case Of course. Here it is.
I don't think the packages are different. I get this after a "zypper dup" has finished, if I run it again, it wants to reinstall almost everything. Even if the repository did not change.
The testcase says that the build times are different, e.g. installed zsh has build time Sep 14 15:56:32, repo zsh has Sep 15 05:30:55. Factory rebuilds a lot...
i hope i won't have to show this in the install summary as well :O))) If this is really intended and needed, can't factory avoid rebuilding unchanged packages?
Heh, things will change soon. When factory is no longer built by autobuild and exclusively in the build service, package release numbers will be of the form "ci count"."rebuild count". So zypper will see a higher release will every rebuild and report hundreds of updates instead of hundreds of reinstalls.
superb! ;-) Would a "--no-buildtime-check" option for zypper be possible?
here`s a "me too" - i had run zypper dup upgrade for hours yesterday - zypper needed to install around 1136 (925mb) of packages. because it was darn late, i suspended the vm (test system only) and hoped, zypper would continue after resume - ok, it didn`t - but after restarting "zypper dup", zypper starts from scratch and installes all of them again. very weird - how can zypper install an rpm without warning, if it`s already there? i checked the repo, but all packages are same version as yesterday.
Created attachment 254154 [details] tgz of /var/log/zypper.log, /var/log/zypp & /var/log/zypper.solverTestCase I can repeat 'zypper dup' as many times in succession as I want, and always when the latest kernel is already installed it will downgrade openSUSE, and reinstall kernel-pae, kernel-pae-base & openSUSE-release.
comment #10: are you by chance using zypper shell there?
I am not using zypper at all for updates due to this bug.
The logs suggests 'zypper shell' was not used.
another "me too". On each run zypper wants to reinstall some packages from Packman where their rpm buildtime is not the same than the ones listed in the xml files that I get with --debug-solver. *Very* annoying. This is on 11.1 btw, w/o factory packages. I can add the resolver testcase, but it's the situation mentioned above already. Oh yes, and there's also bug 472099 that's probably a duplicate to this one. Can we please get the option "--no-buildtime-check"? In addition, please give us a "--explain" option (or add this to some verbosity level) that gives for each installed, upgraded, or reinstalled package the reason why this action has been taken. (more current, new dependency, buildtime changed, etc.) It took me a full hour to track down the root cause behind that obnoxiuos behaviour, and such an option would make our lives really easier, IMHO.
*** Bug 472099 has been marked as a duplicate of this bug. ***
Fisrt step would be a solver option to turn off buildtime-check.
No, "zypper dup" means "make the installed packages identical to the ones from the repositories". If the build times are different, the packages are not identical. Of course this only works if the repositories aren't broken, somebody should notify the packman guys of this. "zypper up" is a different beast, it doesn't look at the build time. You should use 'up' instead of 'dup' to keep your packages up to date.
I think meanwhile all here understood that the behaviour was caused by a bad meta info in a package. (I notified the Packman guys and they repaired it some time ago.) Owing to the bad accessibility of respective data, it just took us a while to get to that conclusion. But that's not the issue at hand. We asked for an *enhancement* of zypper to allow us to handle corrupt repositories better, in a more flexible fashion. After all, one is usually not in the situation to fix the root cause of that problem since we don't own the repositories and thus one needs both robust and flexible behaviour here. Since one very often has dozens of repository, such corruptness can happen again, and added robustness would make zypper better in that case. Simply saying "works as designed" takes away the opportunity to use our user feedback to improve your software, which is a very sad attitude.
You really shouldn't use 'zypper dup' to keep your packages up to date. It's not designed for that purpose.
zypper up may not be designed, but since zypper up ignores repo priorities since 11.1, it's not fit for my purpose either. In fact, since 11.1, 'zypper dup' does a better job for my intentions, namely to give jpackage and Packman packages always priorities over SUSE ones.
Zypper up does not ignore repo priorities. You're probably hit by the vendor locking, just configure zypp so that packman is considered equal to the opensuse vendor. I.e., create a file /etc/zypp/vendors.d/packman that contains: [main] vendors = packman,suse,opensuse