Fedora Core 2 Update: kernel-2.6.6-1.435

[Erik Espinoza]

<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 at drussell.dnsalias.com> 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 at redhat.com
> To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>