This is FC3 w/all updates.
Why does smart want to downgrade gcc today?
sudo smart upgrade Loading cache... Updating cache... ########################################################## [100%]
Computing transaction...
Upgrading packages (4): gcc-3.4.2-6.fc3@x86_64 openoffice.org-i18n-1.1.3-11.5.0.fc3@i386 openoffice.org-1.1.3-11.5.0.fc3@i386 openoffice.org-libs-1.1.3-11.5.0.fc3@i386
Downgrading packages (3): cpp-3.4.2-6.fc3@x86_64 gcc-3.4.2-6.fc3@x86_64 gcc-java-3.4.2-6.fc3@x86_64
Removed packages (5): gcc-c++-3.4.3-22.fc3@x86_64 gcc-objc-3.4.3-22.fc3@x86_64 libtool-1.5.6-4.FC3.2@x86_64 gcc-g77-3.4.3-22.fc3@x86_64 lam-2:7.1.1-1_FC3@x86_64
On 4/14/05, Neal Becker ndbecker2@verizon.net wrote:
This is FC3 w/all updates.
Why does smart want to downgrade gcc today?
This is not the most appropriate place to discuss fc3 update issues. Even if the smart developer watches this list.. a question like that is probably most appropriate in a forum or list dedicated to smart or a forum or list dedicated to end-user discussion of fedora core releases.
Looking at your package set your problem is most likely related to contacting an unsynced mirror which doesn't have the latest updates yet.
-jef
On Thu, 2005-04-14 at 09:54 -0400, Jeff Spaleta wrote:
On 4/14/05, Neal Becker ndbecker2@verizon.net wrote:
This is FC3 w/all updates.
Why does smart want to downgrade gcc today?
This is not the most appropriate place to discuss fc3 update issues.
???
fedora-devel is about development of Fedora. Updates of FC3 are part of it, no matter whether a package involved is part of Core, Extras or elsewhere.
Even if the smart developer watches this list.. a question like that is probably most appropriate in a forum or list dedicated to smart or a forum or list dedicated to end-user discussion of fedora core releases.
Looking at your package set your problem is most likely related to contacting an unsynced mirror which doesn't have the latest updates yet.
If this is true, the issue even is independent of smart.
[FWIW: I repeatedly had seen similar issues happening with yum.]
Ralf
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.
Ralf
On Thu, 2005-04-14 at 17:06 +0200, Ralf Corsepius wrote:
My explanations is that yum was choosing different mirrors in these runs, where it happens to hit mirrors in different states.
I have to admit I just disable the mirror features - it seems to have an uncanny ability to select a mirror at the end of a wet string connection, so I just fix the baseurls to point at a relatively local known reliable mirror.
Nigel.
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
On Thu, Apr 14, 2005 at 12:58:43PM -0400, seth vidal wrote:
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
Me too. I think it's 'cause of too much prompting. :) :) :)
On 4/14/05, Ralf Corsepius rc040203@freenet.de wrote:
???
fedora-devel is about development of Fedora. Updates of FC3 are part of it, no matter whether a package involved is part of Core, Extras or elsewhere.
I feel asking 'why' a tool behaves a certain way is an end-user question that other users of the tool can adequately explain in a lot of cases on par with 'why do I need su -l and not just su'. This type of question is very common in fedora-list and in forums and in irc. I'm not content with watching all questions about basic tool behavior being thrown into the -devel-list.
If you and other people want to discuss the more general question of why mirror sync issues happen.. and what can be done to prevent them or mitigate them in the future and the resulting trade-offs of each technical approach to the problem.. then this list is far more appropriate for that sort of discussion. But that wasn't the point of the original post. Simple fact discovery of tool behavior is an end-user issue.
-jef
On Friday 15 April 2005 01:14, Jeff Spaleta wrote: | If you and other people want to discuss the more general question of | why mirror sync issues happen.. and what can be done to prevent them | or mitigate them in the future and the resulting trade-offs of each | technical approach to the problem..
Download the latest rsync (http://rsync.samba.org/) and use the new --delay-updates option which was largely influenced by the needs of large rpm repositories. It synchronizes the files up to the server and does a rename of the topdir in a pseudo-atomic step. ;)
-
Jef Spaleta -
Jeff Pitman -
Matthew Miller -
Neal Becker -
Nigel Metheringham -
Ralf Corsepius -
seth vidal