Since the Up2date icon has disappeared off the desktop I assume Fedora is going with some other standard way of doing updates.
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror. I am starting to believe that YUMEX uses some random number generator to pick which mirror it uses. At least with Up2date it tells you what channel it is starting with. Does pup and YUMEX use --obsoletes by default ? Who knows ! Up2date lets you decide to install the updates or not after everything is downloaded so you can do that later if you have run out of time. I believe RPM used to have a rollback option but that seems to have been dropped from the latest documentation.
What I am getting at is that the current list of alternatives to up2date while greatly improved in some areas still needs improvement and has regressed in some ways. Compared to the old up2date it is easier to add mirrors to alternate sites like LVN in YUM, Yum tries another mirror if the current one fails and Yum makes resolving dependencies a lot easier.
In Microsoft land the system keeps a list of patches so you can delete them if they fail, has a rollback facility for service packs, has a rollback facility for device drivers in device manager if your new driver sucks, never seems to have broken dependencies and has one central site so you don't have to worry that the mirror is up to date or not. Microsoft updates do break you box sometimes but not more often than "rawhide" updates.
This is one area that I think REDHAT should spend a lot more development dollars on. It would also help if there were more groups for "group update" ie one for Gnome, KDE, Openoffice and Eclipse etc if yum and yumex are the direction things are going. Please take PUP out back and beat it to death with a big stick. BAD DOG !
Don Springall wrote:
Since the Up2date icon has disappeared off the desktop I assume Fedora is going with some other standard way of doing updates.
Yes. Pup along with various other enhancements not implemented yet.
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror. I am starting to believe that YUMEX uses some random number generator to pick which mirror it uses. At least with Up2date it tells you what channel it is starting with.
Yum connects to a random mirror too and lists the mirror name. fastestmirror plugins in yum-utils as part of Fedora Extras might help. Not sure about yumex. If it doesnt do that file a enhancement request on it.
Does pup and YUMEX use --obsoletes by default ? Who knows !
Yes it does.
Up2date lets you decide to install the updates or not after everything is downloaded so you can do that later if you have run out of time
Look at yumdownloader in yum-utils.
Microsoft updates do break you box sometimes but not more often than "rawhide" updates.
Apples and oranges. Microsoft does not provide daily updates of its development branch.
This is one area that I think REDHAT should spend a lot more development dollars on. It would also help if there were more groups for "group update" ie one for Gnome, KDE, Openoffice and Eclipse etc if yum and yumex are the direction things are going.
Try yumgrouplist and yumgroupinstall. See the man page and http://fedora.redhat.com/docs/yum for details. system-config-packages is planned to get a yum backend too. Anaconda already has one now.
Please take PUP out back and beat it to death with a big stick. BAD DOG !
Nah. Just be patient for a while till it gets more functionality during this development cycle and file more feature requests in http://bugzilla.redhat.com.
regards Rahul
On 11/26/05, Rahul Sundaram sundaram@redhat.com wrote:
Don Springall wrote:
Since the Up2date icon has disappeared off the desktop I assume Fedora is going with some other standard way of doing updates.
Yes. Pup along with various other enhancements not implemented yet.
I actually got the full list of available updates from pup yesterday on it's first run. Haven't updated anything but list looked pretty complete. Not sure whether it looked at development or rawhide repo, though.
Microsoft updates do break you box sometimes but not more often than "rawhide" updates.
Apples and oranges. Microsoft does not provide daily updates of its development branch.
Wouldn't that be a fun - MS unstable :o)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Fri, 2005-11-25 at 14:55 -0700, Don Springall wrote:
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror.
pup uses the exact same configuration as yum itself does. Which means that it uses the mirror list by default. One thing we want to do is add a nicer way of doing persistent mirror selection, but I don't know that we'll definitely get to it by FC5. up2date points to the main download site by default (which is less good, IMHO, from a bandwidth perspective)
Does pup and YUMEX use --obsoletes by default ? Who knows !
Again, they use the default configuration as set by yum instead of having their own implementation of this stuff.
Up2date lets you decide to install the updates or not after everything is downloaded so you can do that later if you have run out of time.
Why would you run out of time, though? How is having the time required for downloading different from having the time required for installing?
This is one area that I think REDHAT should spend a lot more development dollars on. It would also help if there were more groups for "group update" ie one for Gnome, KDE, Openoffice and Eclipse etc if yum and yumex are the direction things are going. Please take PUP out back and beat it to death with a big stick. BAD DOG !
system-config-packages is going to get some love to have a backend based on yum as well. There just wasn't time to get it done before test1. One of the things in the works here is reworking the comps file a bit to flesh out the groups and then hopefully we'll also get some help on adding grouping for packages in Extras as well.
Note that yumex is an independently developed application and great for the user who wants an interface which gives you all the options. That's not what we're going for with pup/system-config-packages, though, and instead are more focusing on making it easy for the user to install software.
Cheers,
Jeremy
Jeremy Katz wrote:
On Fri, 2005-11-25 at 14:55 -0700, Don Springall wrote:
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror.
pup uses the exact same configuration as yum itself does. Which means that it uses the mirror list by default. One thing we want to do is add a nicer way of doing persistent mirror selection, but I don't know that we'll definitely get to it by FC5. up2date points to the main download site by default (which is less good, IMHO, from a bandwidth perspective)
Does pup and YUMEX use --obsoletes by default ? Who knows !
Again, they use the default configuration as set by yum instead of having their own implementation of this stuff.
Up2date lets you decide to install the updates or not after everything is downloaded so you can do that later if you have run out of time.
Why would you run out of time, though? How is having the time required for downloading different from having the time required for installing?
This is one area that I think REDHAT should spend a lot more development dollars on. It would also help if there were more groups for "group update" ie one for Gnome, KDE, Openoffice and Eclipse etc if yum and yumex are the direction things are going. Please take PUP out back and beat it to death with a big stick. BAD DOG !
system-config-packages is going to get some love to have a backend based on yum as well. There just wasn't time to get it done before test1. One of the things in the works here is reworking the comps file a bit to flesh out the groups and then hopefully we'll also get some help on adding grouping for packages in Extras as well.
Note that yumex is an independently developed application and great for the user who wants an interface which gives you all the options. That's not what we're going for with pup/system-config-packages, though, and instead are more focusing on making it easy for the user to install software.
Cheers,
Jeremy
will system-config-packages with the yum backend be able to install software from extras and third party repos?
On 11/26/2005 12:00:58 AM, Jeremy Katz wrote:
On Fri, 2005-11-25 at 14:55 -0700, Don Springall wrote:
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror.
pup uses the exact same configuration as yum itself does. Which means that it uses the mirror list by default. One thing we want to do is add a nicer way of doing persistent mirror selection, but I don't know that we'll definitely get to it by FC5. up2date points to the main download site by default (which is less good, IMHO, from a bandwidth perspective)
Like Don I've been annoyed at times with out-of-date mirrors. That makes sequential runs of yum inconsistent. All the time, I see things like:
[root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:01 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Available Packages mach.x86_64 0.4.8-1.fc4 extras [root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 826 kB 00:01 extras : ################################################## 2350/2350 Added 22 new packages, deleted 53 old in 1.59 seconds [root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 838 kB 00:05 extras : ################################################## 2381/2381 Added 53 new packages, deleted 22 old in 1.61 seconds Available Packages mach.x86_64 0.4.8-1.fc4 extras
where a repository oscilates between today's view and some obsolete view.
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
Thanks,Willem Riede.
On Sat, 2005-11-26 at 15:10 +0000, Willem Riede wrote:
On 11/26/2005 12:00:58 AM, Jeremy Katz wrote:
On Fri, 2005-11-25 at 14:55 -0700, Don Springall wrote:
I currently find that updating in fedora is a hit and miss proposition and I do not trust any of them. I ran yumex this morning and it reports nothing to update. The same with pup. I run up2date and it finds updates. Obliviously yumex and pup decided to use some not uptodate mirror.
pup uses the exact same configuration as yum itself does. Which means that it uses the mirror list by default. One thing we want to do is add a nicer way of doing persistent mirror selection, but I don't know that we'll definitely get to it by FC5. up2date points to the main download site by default (which is less good, IMHO, from a bandwidth perspective)
Like Don I've been annoyed at times with out-of-date mirrors. That makes sequential runs of yum inconsistent. All the time, I see things like:
[root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:01 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Available Packages mach.x86_64 0.4.8-1.fc4 extras [root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 826 kB 00:01 extras : ################################################## 2350/2350 Added 22 new packages, deleted 53 old in 1.59 seconds [root@serve ~]# yum list mach Setting up repositories extras 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 838 kB 00:05 extras : ################################################## 2381/2381 Added 53 new packages, deleted 22 old in 1.61 seconds Available Packages mach.x86_64 0.4.8-1.fc4 extras
where a repository oscilates between today's view and some obsolete view.
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
-sv
On 11/26/2005 10:18:45 AM, seth vidal wrote:
On Sat, 2005-11-26 at 15:10 +0000, Willem Riede wrote:
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
So is something like that going to happen, or do I need to give an extra (RFE) nudge? :-)
Thanks, Willem Riede.
On Sat, 2005-11-26 at 15:50 +0000, Willem Riede wrote:
On 11/26/2005 10:18:45 AM, seth vidal wrote:
On Sat, 2005-11-26 at 15:10 +0000, Willem Riede wrote:
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
So is something like that going to happen, or do I need to give an extra (RFE) nudge? :-)
an rfe is not going to nudge anything. Submitting the code is going to make it happen faster.
-sv
On 11/26/2005 10:55:12 AM, seth vidal wrote:
On Sat, 2005-11-26 at 15:50 +0000, Willem Riede wrote:
On 11/26/2005 10:18:45 AM, seth vidal wrote:
On Sat, 2005-11-26 at 15:10 +0000, Willem Riede wrote:
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
So is something like that going to happen, or do I need to give an extra (RFE) nudge? :-)
an rfe is not going to nudge anything. Submitting the code is going to make it happen faster.
So I posted a variant to the fastestmirror plugin that does what I described here: https://lists.dulug.duke.edu/pipermail/yum-devel/2005-December/001715.html but so far noone has reacted to it there - maybe the fedora community has more interest?
Regards, Willem Riede.
On Sat, 2005-11-26 at 10:18 -0500, seth vidal wrote:
where a repository oscilates between today's view and some obsolete view.
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
Well, here's a quick-n-dirty proof of concept version of fastestmirror with persistent cache of mirror response times: http://laiskiainen.org/yum/plugins/fastestmirror/fastestmirror-persistent.py
Certainly makes a big difference, a no-op 'yum update' on my system is around 11s when all mirrors are timed on each run, with the above version the consecutive runs come down to ~5s.
- Panu -
On Sun, 2005-11-27 at 19:02 +0200, Panu Matilainen wrote:
On Sat, 2005-11-26 at 10:18 -0500, seth vidal wrote:
where a repository oscilates between today's view and some obsolete view.
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
Well, here's a quick-n-dirty proof of concept version of fastestmirror with persistent cache of mirror response times: http://laiskiainen.org/yum/plugins/fastestmirror/fastestmirror-persistent.py
Certainly makes a big difference, a no-op 'yum update' on my system is around 11s when all mirrors are timed on each run, with the above version the consecutive runs come down to ~5s.
is this including the repomd.xml caching?
-sv
From: seth vidal skvidal@phy.duke.edu Reply-To: For testers of Fedora Core development releases fedora-test-list@redhat.com To: For testers of Fedora Core development releases fedora-test-list@redhat.com Subject: Re: Up2date replacement Date: Sun, 27 Nov 2005 17:22:44 -0500
Well, here's a quick-n-dirty proof of concept version of fastestmirror with persistent cache of mirror response times:
http://laiskiainen.org/yum/plugins/fastestmirror/fastestmirror-persistent.py
Certainly makes a big difference, a no-op 'yum update' on my system is around 11s when all mirrors are timed on each run, with the above version the consecutive runs come down to ~5s.
Well I gave your plugin a spin, seems to work as advertised, however saw this message: http://mirrors.kernel.org/fedora/core/development/i386/repodata/primary.xml....: [Errno -1] Metadata file does not match checksum Trying other mirror.
Is this an indication that the first mirror picked was out of date with the repo file from Fedora ?
On Sun, 27 Nov 2005, Don Springall wrote:
From: seth vidal skvidal@phy.duke.edu Reply-To: For testers of Fedora Core development releases fedora-test-list@redhat.com To: For testers of Fedora Core development releases fedora-test-list@redhat.com Subject: Re: Up2date replacement Date: Sun, 27 Nov 2005 17:22:44 -0500
Well, here's a quick-n-dirty proof of concept version of fastestmirror with persistent cache of mirror response times:
http://laiskiainen.org/yum/plugins/fastestmirror/fastestmirror-persistent.py
Certainly makes a big difference, a no-op 'yum update' on my system is around 11s when all mirrors are timed on each run, with the above version the consecutive runs come down to ~5s.
Well I gave your plugin a spin, seems to work as advertised, however saw this message: http://mirrors.kernel.org/fedora/core/development/i386/repodata/primary.xml....: [Errno -1] Metadata file does not match checksum Trying other mirror.
Is this an indication that the first mirror picked was out of date with the repo file from Fedora ?
Yep, that's business as usual, the plugin sorts the mirrors based on speed and doesn't know anything about them being up to date or not. In the above case yum just goes to the second fastest mirror when the fastest one doesn't work.
- Panu -
On Sun, 27 Nov 2005, seth vidal wrote:
On Sun, 2005-11-27 at 19:02 +0200, Panu Matilainen wrote:
On Sat, 2005-11-26 at 10:18 -0500, seth vidal wrote:
where a repository oscilates between today's view and some obsolete view.
Perhaps I should file a yum RFE to make yum not only select mirrors for access speed, but also for the recentness of their metadata file?
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
Well, here's a quick-n-dirty proof of concept version of fastestmirror with persistent cache of mirror response times: http://laiskiainen.org/yum/plugins/fastestmirror/fastestmirror-persistent.py
Certainly makes a big difference, a no-op 'yum update' on my system is around 11s when all mirrors are timed on each run, with the above version the consecutive runs come down to ~5s.
is this including the repomd.xml caching?
No, that's just plain 2.4.0.
- Panu -
seth vidal wrote:
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
I for one am not sure that "fastest mirror" is the one I want to use.
There are financial benefits to many people in Australia using their local cache peering arrangements.
When it comes to dialup, I can't imagine I'd notice a difference between a site on Westnet (my IAP) or one in Helsinki.
We need to be given the chance to choose a mirror, and to know where that mirror is: the name www.au.fedoracore.org doesn't tell me whether it's in QLD, WA, or even off-shore in TAS.
On Mon, 2005-11-28 at 14:47 +0800, John Summerfied wrote:
seth vidal wrote:
what we had considered was using the fastest mirror plugin to sort the list of mirrors. Then store that sorted list in the repo cache directory. Then redownload the list and re-sort/store it every 8 hours or so, same as how we're storing the repomd.xml data, now.
I for one am not sure that "fastest mirror" is the one I want to use.
There are financial benefits to many people in Australia using their local cache peering arrangements.
Then you need to specify your own mirrorlist or look to see if the australia-only mirror list is up.
We need to be given the chance to choose a mirror, and to know where that mirror is: the name www.au.fedoracore.org doesn't tell me whether it's in QLD, WA, or even off-shore in TAS.
You can choose a mirror, type it in the baseurl and remove the mirrorlist.
-sv
On Mon, 28 Nov 2005, seth vidal wrote:
Then you need to specify your own mirrorlist or look to see if the australia-only mirror list is up.
It would be nice if there were some repository config manager, which pulled a master "authoritative" list from somewhere and let you select repositories via ncurses/x11/etc. The directory would list the repository name, its intended function, its geographic location and link speeds, etc. to make sorting out the whole mess a bit easier.
I have thought about writing such a beast and calling it "yuk" to complement "yum" :)
-Dan
On Mon, 2005-11-28 at 10:19 -0800, Dan Hollis wrote:
It would be nice if there were some repository config manager, which pulled a master "authoritative" list from somewhere and let you select repositories via ncurses/x11/etc. The directory would list the repository name, its intended function, its geographic location and link speeds, etc. to make sorting out the whole mess a bit easier.
I have thought about writing such a beast and calling it "yuk" to complement "yum" :)
Such a tool, or such information that the tool uses to get the list of repos must live outside the scope of Fedora. Fedora tools/content cannot link to, point to, or otherwise enable the use of repositories that may include illegal or ForbiddenItems content.
Jesse Keating wrote:
On Mon, 2005-11-28 at 10:19 -0800, Dan Hollis wrote:
It would be nice if there were some repository config manager, which pulled a master "authoritative" list from somewhere and let you select repositories via ncurses/x11/etc. The directory would list the repository name, its intended function, its geographic location and link speeds, etc. to make sorting out the whole mess a bit easier.
I have thought about writing such a beast and calling it "yuk" to complement "yum" :)
Such a tool, or such information that the tool uses to get the list of repos must live outside the scope of Fedora. Fedora tools/content cannot link to, point to, or otherwise enable the use of repositories that may include illegal or ForbiddenItems content.
No Fedora mirror would have such content: if it did, it would clearly not be a Fedora mirror.
Further, only the Fedora ftp master knows who mirrors the site; I am assumiming that if I want to run an official mirror then I can have special access.
The master list should, I think, be packaged as a Fedora Core package: when it changes, users get an updated list via their usual channel.
Jeremy Katz wrote:
Up2date lets you decide to install the updates or not after everything is downloaded so you can do that later if you have run out of time.
Why would you run out of time, though? How is having the time required for downloading different from having the time required for installing?
I use up2date on FC3, principally because it can download separately from installing. It also can get source and does some other things yum couldn't.