On Mon, 2004-06-14 at 23:17, Don Russell wrote: > 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? > All the mirror sites poll the main server for updates using rsync (well , as far as I know... dont know if some use other methods) > 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. > Not a lot. Most mirrors have a short interval between syncs (30 minutes usually)[considering the information for mirrors of fedora.us , which is very similar to the common mirroring practice used by most mirror admins]. Others have a larger interval (when I had a mirror at work, I used to sync it daily). > 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. Well , I considered it a waste because I didnt dig enough... All you need to get is the directory listing , which is just a few KB (16KB as of today). Probably a wise use of the correct HTTP headers can save some KB during the day, by just getting recently modified indexes (but I guess this wouldnt work , because for the main RH server , the index page for the updates directory is generated on demand by the web server... maybe I'm saying some stupid things here, because I never studied the HTTP protocol .. just used it on a daily basis ;P ) > 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. > I agree. Maybe we could find a good way to detect these changes , code them in python and then post it in bugzilla as a RFE with a patch... > 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) > Probably this is the reason. (I dont know for sure , as I installed FC2 from scratch). Here , a rpm -q --provides shows that the cdrecord package provides dvdrecord now. Just remove your dvdrecord package and things will work. -- Pedro Macedo
