Description of problem:
i can't 'yum update' because gnome-applets claims to need libgucharmap.so.5 but
package gucharmap has moved on to libgucharmap.so.6
Version-Release number of selected component (if applicable):
i know this happens less in released systems but i think this is important
because it's a very visible part of the user experience. new users get
extremely frustrated when the system they're trying to familiarise themselves
with says "there's new packages to install. click here!" and then says
"actually, i can't install them".
surely it's not too difficult to use automatic dependency checks to ensure that
it's impossible for this sort of thing to happen?
apologies. looks like a 'yum clean all' has solved this.
mind you, the point still stands - this does happen occasionally in released
fedora, it is extremely frustrating, novice users shouldn't need to 'yum clean
all' and it should be automatically avoidable.
You shouldn't have needed to yum clean all.
We needed to rebuild gnome-applets against the new gucharmap and we didn't get
it done before the compose, so things were temporarily broken.
Just temporary rawhide breakage, that kind of thing shouldn't happen in released
Hi Ray. thanks for the info. just for extra-super-clarity on this:
are you saying this shouldn't happen in released versions because there exists
an automated checking system which either isn't present or is disabled in
rawhide? or because people will be more careful in a released version?
if the latter then can i suggest that this is too important to rely on people
being careful and there should be an automatic checker which means that this
_can't_ happen, rather than _shouldn't_ happen?
sorry to go on. (by the way, it often appears that 'yum clean all' resolves yum
problems but i guess it's hard to tell if it's really that or just picking up a
different random mirror that's made the difference.)
It's more the latter. When we release updates we're more careful.
The daily rawhide reports (on fedora-test-list and fedora-devel-list) mention
any broken dependencies the night after they happen, so they don't normally stay
broken for very long.
I agree with you though. It would be better if it were enforced a priori.
thanks again for the info.
since i'm not aware of an existing bug for automatic dependency checking i'd
like to create one. can you suggest what component and version it should be
filed under? i'm leaning towards devel and Package Review.
i suspect people might say that it should be discussed in the mail lists but
i've seen a few heated threads already and i think we'd have a better chance of
getting somewhere if those threads all ended with "see bug xxx".