Pedro Fernandes Macedo said: > On Mon, 2004-06-14 at 21:09, Don Russell wrote: >> So.... could the list of mirrors eligible for participating in up2date >> be >> updated dynamically so as only synch'd mirrors would be used by up2date? <SNIP> > This is a interesting idea. The problem is how to create such list. <SNIP> This depends on how the synch process occurs. Let's start at a known point: all mirrors are in synch. Now, redhat releases a new version of "thingy", puts it on their own site and announces it to the world: New thingy is now available! Can redhat 'push' the new thingy version to a mirror? Or is it up to the mirror site to poll for updates? If redhat can push the update to the mirrors, then upon a new set of updates being available, the list of mirrors eligible to participate in up2date is reduced to the single redhat site. As redhat pushes the updates to the mirrors, and those transfers complete, the newly updated mirror site is, once again added to the list of mirrors eligible to serve up2date. On the other hand, if redhat does not push file updates to the mirrors, then there can be a very large delay in mirrors getting synch'd again because now you're on somebody elses schedule. Back to your idea of a cron job that lists all files from the mirror and diffs them.... that would not take as much bandwidth as you might think... the list of files to get can be optimized by getting only files updated since a specific date/time... the last date/time the mirror was known to be synch'd. In either case this results in up2date always showing accurate counts etc, because it would only ever look at synch'd mirrors (and the "base" redhat site). This would improve the reliability of up2date. Even if I understand why up2date fails, it's still frustrating when it doesn't work "properly" and I have to try repeatedly to do what should be a simple task. >> Right now I have a red ball exclaming "There be updates! ... There be >> updates!" ... It says 5 are available... when I launch up2date, I see >> only >> 3... two of which appear to be mutually exclusive >> (cdrecord/cdrecord-devel) >> > They're not mutually exclusive. They're complementary.. cdrecord-devel > contains stuff needed to make programs based on cdrecord... And cdrecord > contains the cdrecord itself... When I select them both to be installed I get an error: Test install failed because of package conflicts: file /usr/bin/dvdrecord from install of cdrecord-2.01-0.a27.4 conflicts with file from package dvdrecord-0.1.5-1 file /usr/share/man/man1/dvdrecord.1.gz from install of cdrecord-2.01-0.a27.4 conflicts with file from package dvdrecord-0.1.5-1 I don't know what I ever did to get in this situation... but I see now that they are not mutually exclusive.... I just have some sort of problem with an older version I guess... (I did an upgrade of FC1 to FC2) >> Is the count mismatch due to different mirrors having different software >> at different times? Once all the mirrors are in synch then up2date will >> report things more accurately? > > Exactly. Each mirror takes a different time to sync with redhat. Some > sync faster , some sync slower. As soon as all mirrors are in sync , > up2date will show the right thing... OK... so I AM learning... :-) Don Russell
