It is time for this thread to die! But no-one seems to have
a wooden stake or a silver bullet!
I have collected a few comments below with my response:
"But the updates in the stable updates you pointed to are NOT the ones
which caused that. Your KDE 4 must be coming from Rawhide (development)
or kde-redhat unstable."
No longer true. Which is part of the fog which enveloped the start of
this thread. If you look at any of the update mirrors, such as
http://linux.nssl.noaa.gov/fedora/linux/updates/8/i386
you will find kdebase4, kdelibs4 and kdebase-runtime (4.0.1...etc). I
suppose those *were* in dev, but are no longer (February 20th)
"After a brief following of this thread, I am unable to see how this
could happen. However, the yum logs could help us understand, and if
necessary, avoid this in the future. Could you please post the last part
of your yum log - ie the part from say the date before when you were
adding the extra packages. This is found in /var/log/yum.log {or if it
was rolled over recently in /var/log/yum-2008????.log
Also, were any updates done using rpm directly ?"
The yum logs are long gone. I nuked it and started again. But I do not
now need them to know what happened.
"Well, I have kde4 too, but I had to take action to get it. I had to
enable the development repo(s), and then I track rawhide until f9."
That must have been prior to February 20. I did NOT have dev enabled.
FEDORA-UPDATES.REPO IS ENABLED BY DEFAULT (confirmed by a bare metal
install this morning).
"Okay, adding atrpms to the mix can surely complicate your life a bit.
If you enable atrpms you can end up pulling in more than you want.
I'd recommend disabling it by default and then selectively enabling it
at the command line when you want to install a specific package from
there."
"Also note that you could easily install mplayer and all of its deps
from livna (or atrpms - but don't try mixing the two without a lot of
care)."
As far as I am aware the repo mplayer rpms are not xvmc enabled
(leastways, they have never run with '-vo xvmc -vc ffmpegmc' (whatever)
for me). And you still need faac, faad, lame etc. *and their devel
packages* to compile mplayer. That is what I was trying to do. And that
is ALL I was trying to do.
> > And I think I can still call 'stupid' on the maintainers.
"No, you can't do that yet. You've provided no evidence that they made
any packaging mistakes that caused the mess you find yourself in."
I think I can: on 2 points. 1) Yum often fails, because packages on the
release mirrors are NOT signed. If I download directly, the software
installer asks for approval to continue with the install. I suppose that
yum's db then gets out of sync.
2) It appears that the kde4 update did NOT install ALL of the packages.
I do NOT know explicitly. But I will note that attempting to
back out, by a 'grouperase "KDE" (or '"KDE Software Development") with
updates enabled, followed by groupinstall with it disabled, failed on
the install with dependency errors. Yum could NOT find programs with the
proper version number...so grouperase or even erase, is broken somewhat.
"Please don't simply discourage people from using a repo w/o checking
whether this issue has anything to do with their problem. There is
nothing from kde4 in ATrpms, I think the OP was angered about wanting
to update/install something completely irrelevant to kde and he got a
kde4 upgrade w/o him noticing due to using yum -y. But that's just the
way yum update works."
Thank you Axel. This problem has NOTHING to do with atrpms (except for
the leftover question of what it was that triggered the update? I don't
think it was something ON atrpms, I think it was merely that updates
were available, but I may be wrong, but in that case, it was likely a
cascade effect where something on atrpms called for a 'new' something,
which wanted a 'newer' whatever.....
">>I'd recommend disabling it by defaultand then selectively enabling it
> > at the command line when you want to install a specific package from
> > there."
"No, please don't. If you do that, then better don't use the repo at
all. This practice leads to phantom bugs that people then consider
being caused by ATrpms which is not correct."
And I follow Axel's advice on this matter.
SYNOPSIS:
1. DANGER WARNING. Updates are not commutative nor reversible.
2 DANGER WARNING. The Updates repo is enabled by default.
3. The kde4 rpms may be packaged improperly, such that not all are
installed.
4. An analysis of the naming scheme for kde4 shows that it is not
regular and not globbable, which makes install reversal difficult, if
not impossible when coupled with '3'.
5. Not all packages on the mirrors are properly signed and
authenticated, which causes some installs or updates to fail improperly
(especially as those packages can be manually installed with the "Softwa
re Installer".
Way back in the beginning someone noted that the fastest fix is a
re-install. And that advice is, unfortunately, true!
Thanks for the memories...this thread is DEAD.
Geoff
