<sarcasm> how bout we just go to windowsupdate.com like the rest of the world </sarcasm> On Mon, 14 Jun 2004 19:17:17 -0700 (PDT), Don Russell <don@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 > > > > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list >
