Hello,
pm-utils-0.99.3-6.fc7 and pm-utils-0.99.4-3.fc7 have a ping-pong
upgrade/downgrade problem which bites smart: pm-utils-0.99.3-6.fc7 obsoletes
(unversioned!) radeontool and vbetool, pm-utils-0.99.4-3.fc7 requires them
(unversioned too), resulting in:
# rpm -q pm-utils radeontool vbetool
pm-utils-0.99.4-3.fc7.x86_64
radeontool-1.5-2.fc7.x86_64
vbetool-0.7-2.fc7.x86_64
# smart upgrade
[...]
Upgrading packages (1):
pm-utils-0.99.3-6.fc7@x86_64
Downgrading packages (1):
pm-utils-0.99.3-6.fc7@x86_64
Here smart decides to downgrade to pm-utils-0.99.3-6.fc7 because it sees it
obsoletes the installed radeontool and vbetool versions. Once the downgrade
is done, vbetool and radeontool are gone too. The "Upgrading packages"
message looks like a smart bug, ditto the fact that it doesn't say beforehand
that it's going to remove radeontool and vbetool. Anyway, after that
transaction:
# smart upgrade
[...]
Upgrading packages (1):
pm-utils-0.99.4-3.fc7@x86_64
Downgrading packages (2):
radeontool-1.5-2.fc7@x86_64 vbetool-0.7-2.fc7@x86_64
Ok, back we go to 0.99.4-3.fc7, and get radeontool and vbetool back too.
After that, again:
# smart upgrade
[...]
Upgrading packages (1):
pm-utils-0.99.3-6.fc7@x86_64
Downgrading packages (1):
pm-utils-0.99.3-6.fc7@x86_64
Etc etc. Duh. yum does not appear to be affected by this. I suppose this
could be argued to be a bug either in smart or yum (I don't have that strong
opinions about which one it is although yum behaves in the desired way in
this particular case), but it once again provides one example why unversioned
Obsoletes and Provides are bad (which is why I'm posting here instead of
reporting this to Bugzilla).
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?
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
