Bug 126667 - up2date incorrectly reports "no updates available"
Summary: up2date incorrectly reports "no updates available"
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
URL: http://www.redhat.com/archives/fedora...
Keywords: FutureFeature
Depends On:
Blocks: 124619
TreeView+ depends on / blocked
Reported: 2004-06-24 15:21 UTC by Don Russell
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-24 20:35:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Don Russell 2004-06-24 15:21:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608

Description of problem:
Often when I use up2date to check for updates, some updates are
reported. Then I try to get the updates and it reports no package found.
I started a thread in fedora-list and think I have a good solution...
ref: http://www.redhat.com/archives/fedora-list/2004-June/msg03798.html 
I'll summarize it here...
-Up2date contacts a server which tells it where to get updates from
 (that list of mirrors should be dynamic so as to only report synch'd
This is accomplished by:
When new packages are ready to be distributed....
- reset the list of sites that serve up2date to the single master site
- move new versions of the pakages to the master site.
- start a cron job in xxx minutes (gives some mirrors a chance to
the cron job does:
- for each mirror site (not already known to be synch'd)
   - get directory listing
   - compare to master directory listing
   - if directory matches, site must be synch'd
        - make mirror site eligible to participate in serving up2date
After checking all mirrors, if one or more are still not synch'd, schedule
the job again in xxx minutes
If all mirrors are now synch'd, we're done.
If something like this could be done, then up2date would only see
synch'd sites and the problem is solved.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Read an "update announcement" for a fedora component
2. Run up2date
3. it may or may not find the update

Actual Results:  [root@P4 root]# yum check-update
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Fedora.us Extras (Stable)
Server: Livna.org - Fedora Compatible Packages (stable)
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Name                                Arch   Version                  Repo
dhclient                            i386   2:3.0.1rc14-1
Immediatly after ...

[root@P4 root]# yum update dhclient
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Fedora.us Extras (Stable)
Server: Livna.org - Fedora Compatible Packages (stable)
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
No Packages Available for Update
No actions to take
[root@P4 root]#

Expected Results:  The updates should have been found and installed.

Additional info:

Comment 1 Don Russell 2004-06-24 16:45:56 UTC
I should have included this in the original text...
I see this a "server side" fix, if up2date works the way I think it 
does (asking a common server for a mirror site to use) then no change 
at the client-side is required. The above solution will guarantee 
that up2date only sees synch'd sites.
Cummulatively this will save a lot of bandwidth and people-hours 
because up2date won't be run over and over and over again trying to 
get updates unsuccessfully.

Comment 2 Kenneth Porter 2004-07-03 06:53:01 UTC
An idea I came up with for another application:

Create a scripted Apache error document that returns a 302 (document
moved) and the location on a mirror known to have the desired update.
A cron job periodically collects file listings from all mirrors to
update the database used by the error document.

This could even be hosted locally, needing only the master file list
and the list of mirrors from the master server. You could serve those
by rsync to cut the bandwidth needed. 

Comment 3 Don Russell 2004-07-03 13:08:44 UTC
Kenneth, that's not so much "another application" as it is another
"implementation" (of the same application)... :-)

It looks like a nice refinement to the original idea... an
"up2date/yum/apt whatever) request goes to the redhat server, where it
gets a "this is temporarily moved to <synch'd site>" brilliant! Then
NOTHING has to change at the client side... (Unless the client side
doesn;t know what to do with that response)

I don't see the benefit of "hosting it locally"... Maybe I'm not
understanding what "it" is... :-)

I don't see a benefit of keeping a list of synch'd sites on my machine
since that list can be obsoleted any time... that means the first
thing I have to "up2date" is the list of servers... On the other hand
if the main server just replies with "file temporarily moved to
<synch'd site>, then I don't care what the sites are, the main server
sends me somewhere that has what I want..

Round-robin or random, as long as only synch'd sites are used, update
should work much better than it does now. :-)

Given the volume of people getting updates, I don't see any benefit of
choosing a random site... simply picking the next one in the list is
"random enough".

The point really is that the solution is not at the client side....
this has to be fixed at the server end...

Or... maybe uppdates can be distributed by bittorrent... it seems like
a perfect application... a new software thing is released... thousands
want it at the same time... then no traffic until the next update...

That's more work though... not a bad idea, just more work. :-)

So... now that it's IN bugzilla... how do we get "somebody with
influence" to look at it/do it? :-)

Comment 4 Don Russell 2004-07-03 17:50:13 UTC
Seems when I updated this, it removed the QA contact... I'm trying to
add that back now...

Comment 5 Pedro Fernandes Macedo 2004-07-06 03:16:08 UTC
About the first comment (and the original thread on fedora-list), I've
implemented a script in perl that compares a set of mirrors with a
server defined as being the original server. 
The script produces as output a file , fedora-core-$releasever , using
the same format as used by up2date's mirror file (using $ARCH instead
of yum's $basearch). It's run every 30 minutes against the redhat
server and all the http mirrors available. 
The code is available at http://www.dcc.ufmg.br/~pmacedo/fedora , and
needs two files , all available in the same place (the config file and
the mirror list).
This code is just a proof of concept about the original thread and
many things can be implemented to improve it , specially in the mirror

Comment 6 Matthew Miller 2005-04-26 16:15:47 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 7 Don Russell 2005-09-23 22:45:19 UTC
I changed the version from FC2 to FC4 because this problem still occurs.

Because this had so many problems, I really stopped using it, and now use yum.

Should up2date be fixed? hmmm, maybe just removed. :-)

Well, that didn't work... apparently I'm not "sufficiently authorized" to change
the version number in the problem report, I get to create a new report... no
thanks, been there, bought the T-Shirt. It's just not that important to me. :-)

So, I guess this will just be relegated to the annals of time...

Comment 8 John Thacker 2006-04-24 20:35:07 UTC
"Should up2date be fixed? hmmm, maybe just removed. :-)"

Well, it has been removed.  Of course, something similar occasionally
occurs in yum-- the mirror hit to see what updates are available isn't
always the first mirror chosen to download packages from, and since
the mirrors aren't always in sync...

But I suppose this can be closed, since up2date isn't even in FC5.

Note You need to log in before you can comment on or make changes to this bug.