On Thu, 2005-04-14 at 17:06 +0200, Ralf Corsepius wrote: > On Thu, 2005-04-14 at 10:37 -0400, seth vidal wrote: > > > If this is true, the issue even is independent of smart. > > > > > > [FWIW: I repeatedly had seen similar issues happening with yum.] > > > > you've seen yum try to downgrade a package? > No. > > > Wow, i'd love to see that. could you show me a screenshot of that > > happening? > There seems to be a misunderstanding. What I have seen happening is yum > behaving differently in consecutive yum run. > > E.g. I've seen the following: > # yum check-update > [reports a couple of packages to update] > > # yum update > [doesn't upgrade] > > My explanations is that yum was choosing different mirrors in these > runs, where it happens to hit mirrors in different states. > > > When the libtool issue occurred, a couple of days ago, this produced > funny effects: > > Consecutive "yum update" runs either bombed out with "broken > repository", upgraded a couple of packages, or had found nothing to > upgrade. > > My explanation: Different mirrors where in different states of sync. > Depending in which shape the currently chosen mirror and the current > state of the system was, yum updated some older packages, found the > libtool<->gcc conflict, etc. > which is not, AT ALL, the same as giving the user a process to continue to that will put their system in a questionably functional state. How many users do you know that will just type 'yes' at every prompt? I know a lot of them. That's a good reason, alone, to not allow downgrade/removal paths that the user did not explicitly select. -sv
