Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157165 - Needs 'single component loop' mode for massive up2dates
Summary: Needs 'single component loop' mode for massive up2dates
Keywords:
Status: CLOSED DUPLICATE of bug 157149
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-08 00:25 UTC by Bob Gustafson
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-08 02:45:36 UTC


Attachments (Terms of Use)

Description Bob Gustafson 2005-05-08 00:25:44 UTC
Description of problem:

  up2date works well for updating a single component, or nightly
updates of a few components. However, if you download the test CD images,
install, and then do an update, there is a massive number of components
that need updating - and up2date just cannot cope.

(This is particularly the case when several weeks have gone by since
the CD images are available)

There are several problems in the massive update process. If there is
a failure in one update, then the whole run is scrubbed. Unfortunately,
there is a high probability of a 404 error in download, or some other
problem in one or more components. With the existing process, one just
waits until some unseen demon slaving away in the server fields corrects
the problem, or one hopes that there is enough randomness in the server
selection algorithm that a different (with correct contents) server is selected
for that component.

Also, the pre-requisite determination algorithm is probably not O(0) -
thus the more things that require update, the longer it takes (and more
memory, etc) to come up with a complete list.

----

So, how have I coped? I just wrote a script wrapper around up2date.
It asks up2date for a list of components which need updating and
then goes through the list one by one. This has the advantage that
a failure knocks out only that one component - the process can trudge
on. When through one pass, the number of components left to be caught
on the second pass are only those that failed - a much smaller number.

Another advantage is that the up2date process can go on unattended.
(So far, I am into 12 hours on a Gateway Solo 2150. The bottom is
quite warm, the network speed seems to be upwards of 100kB/s, and
there is a high probability that by tomorrow, it will be pretty well
updated).

The disadvantages are that there is considerable duplication in
redoing the header download, etc. each time. Also, if a component
has pre-requisites, these pre-requisites are loaded again (if they
are lower in the initial list). The script can sense these and
remove those components from the list, but my script was originally
for yum and I have not adjusted the parsing for the new up2date version.

----

So, it would be nice if up2date would have a mode which would do
what the script does - and eliminate the redundancies within up2date.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Bob Gustafson 2005-05-08 02:45:36 UTC

*** This bug has been marked as a duplicate of 157149 ***


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