Fedora Core 2 Update: kernel-2.6.6-1.435

[Pedro Fernandes Macedo]

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