> I know I'm a little late to the party here, but the same thing happened to me > with a customer machine. The sequence of events went something like this: > > 1. Install FC3. > 2. Install MySQL 4.1.11 RPMs from mysql.com > 3. Run 'yum -yd 2 update' > 4. Observe that the MySQL 4.1.11 pieces are gone, some of which have been > replaced by the FC3 3.23.x versions. So its NOT Amarok! (telling yum to pull in mysql 3x.) > The root problem is that a non-distro RPM (I don't like this thread's > calling them "non-standard" RPMs, as this RPM comes from MySQL > directly) was in the system, and Yum didn't know what to do. Listen. I write software too. If my software would do something CLOSE to this I'd be shot. (ok, ok. I did do a del *.* on a customer cpm a:>prompt.) imho, Yum should KNOW which rpm is standard and if not, either leave it alone or at least double check even with the -y option. Also Yum (well the rpm system) should understand the differences of distros. eg glibc 2.3.5 of FC *4* is greater than 2.3.6 from FC*3*. > Personally I don't think it did the right thing, but I accepted that > the responsibility is mine for running yum. Agreed. > We don't run yum at all on this box anymore; and since the box is in > a protected network, we don't see a need to seek out an alternative > update mechanism. > Can't really blame you, but yum has worked wonders for me, automatically updating tons of pkgs. -nat
