smart fails to upgrade existing packages

[Rehan Khan]

Imported: http://tracker.labix.org/issue208
Reason for Import: Issue Review. Should smart re-install packages that have been re-built without a version/epoch change? Probably not, we should expect good packaging practice and not cover it up? Quick read and close?

[Rehan Khan (rasker)]

msg744 (view) Author: netmask Date: 2006-10-06.17:00:07

Although it's a packaging issue (the packager *should* bump the release number),
I agree that Smart could handle this better.

We have to options here: (a) make Smart simply ignore the package or (b) queue
it under re-install. I'm more favorable to go into (b).

In the mean time, if it really bothers you, run Smart with "-o rpm-force=True".
But don't forget: this *is* a packaging issue.

Ps.: Anyone willing to propose a patch is very welcome.

msg730 (view) Author: ahanke Date: 2006-09-30.10:10:49

The problem persists, as seen in the attachment "issue208-attempt.png":

Package libzypp has been updated to a new, binary incompatible version (2.1.0 ->
2.2.1). This means that all its direct dependencies have to be rebuilt.

libzypp's direct dependencies are:

- libzypp-zmd-backend
- yast2-perl-bindings
- yast2-pkg-bindings

And indeed they were rebuilt, but without bumping the release number. This means
that they have to be reinstalled, but it isn't a "real" reinstallation because
the packages are different and have different dependencies despite the identical
release numbers.

Although this situation is very broken, smart resolves it correctly:

- It reinstalls those of libzypp's direct dependencies which have been rebuilt
- It drops yast2-gtk, because it hasn't been rebuilt for the new libzypp version
- It installs GraphicsMagick which is now needed for unrelated reasons

But the actual transaction fails with the following error message if
rpm-force=False:

package libzypp-zmd-backend-7.1.1.0_0.4-5 is already installed
package yast2-pkg-bindings-2.13.96-2 is already installed
package yast2-perl-bindings-2.13.10-5 is already installed

This doesn't fail with rpm-force=True and IMHO it shouldn't fail, just like
downgrades and "real" reinstallations don't fail even with rpm-force=False.

Rationale: There is no reason for a reinstallation triggered by dependencies to
fail if downgrades triggered by dependencies are succeeding.

msg718 (view) Author: stuartn Date: 2006-09-20.02:17:50

Again, thanks for your help on this!

msg716 (view) Author: ahanke Date: 2006-09-20.02:10:35

The file system clash between nautilus and gnome-filesystem is a SUSE packaging
bug, not a smart bug, and already known to Novell:

https://bugzilla.novell.com/show_bug.cgi?id=201729

Let's restrict ourselves to smart bugs here. The original issue is a smart bug,
but the last comment is not.

What they have in common is the fact that using rpm-force=True resolves them:

smart <command> -o rpm-force=True

smart refusing to install conflicting packages is desirable, but the issue in
the original report is not.

msg715 (view) Author: stuartn Date: 2006-09-20.02:03:02

Thanks, I had not suspected this as the explanation. I have some similar
problems with a conflict as set out below. Do you think it is dangerous
to use rpm-force?

# smart install evolution gnome-applets
Loading cache...
Updating cache... ########################################
[100%]

Computing transaction...

Installing packages (11):
   control-center2-2.16.0-2@i586 gnome-panel-2.16.0-2@i586
   evoluti...

[Gustavo Niemeyer (niemeyer)]

There's no way for Smart to handle this better, unfortunately. Smart trusts the
metainformation that is given to it. If the metainformation is wrong, Smart won't
be able to compute relationships correctly.