pm-utils ping-pong upgrade/downgrade problem in F7

Ville Skyttä ville.skytta at iki.fi
Sat Sep 29 08:56:36 UTC 2007


On Friday 28 September 2007, Michael Schwendt wrote:
> On Thu, 27 Sep 2007 22:36:56 +0000 (UTC), Kevin Kofler wrote:
> > Ville Skyttä writes:
>
> When the installed set of packages is not broken, i.e. the latest
> pm-utils requires the installed radeontool/vbetool pkgs without broken
> deps, why does Smart even look at the older pm-utils pkg?

I can see Obsoletes making it hard to decide what's older.  Sure, pm-utils in 
F7 is older than the one in F7 updates if you only look at the pm-utils EVRs, 
but the troublemaker unversioned Obsoletes on radeontool and vbetool in the 
F7 pm-utils also make it newer than radeontool and vbetool in F7 updates and 
the mess begins.  I suppose if Smart wouldn't consider updating something for 
which it needs to downgrade something unless explicitly told to, we wouldn't 
see the problem in this particular case.  Or something :)

> > > I'm not sure about this and haven't tested, but I guess adding
> > >     Obsoletes: pm-utils < %{version}-%{release}
> > > to the new pm-utils could help smart get over it.  Thoughts?
>
> Hmm... but it's already that a new version-release of a pkg implicitly
> replaces an old version-release, because that is how updates work.

Adding some odd redundant-looking explicit Obsoletes to emphasize 
what we want has however been a cure for some similar looking corner case 
depsolving problems (nothing related to Smart in particular) before, so 
that's the first thing I thought trying in this case.

> Effectively, you would try to add something only to get Smart not
> look at the old version-release anymore.

Sure, assigning a negative priority for the pm-utils package in the F7 release 
repo works around it.  I have no problem doing that locally [0], but just 
wanted to use this case as yet another example why unversioned Obsoletes are 
practically always a bad idea.  Ditto often but not always unversioned 
Provides.

[0] Well, except that setting negative priorities on the command line is 
currently broken at least in Smart 0.51, workaround is to do it in 
smart --gui.  http://tracker.labix.org/issue306




More information about the fedora-devel-list mailing list