Bug 157149 - Needs 'single component loop' mode for massive up2dates
Summary: Needs 'single component loop' mode for massive up2dates
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bret McMillan
QA Contact: Fanny Augustin
URL:
Whiteboard:
: 157165 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-07 16:15 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: 2006-11-05 16:31:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bob Gustafson 2005-05-07 16:15:40 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:43 UTC
*** Bug 157165 has been marked as a duplicate of this bug. ***

Comment 2 John Thacker 2006-10-29 20:30:35 UTC
up2date was replaced by pirut and put (package pirut) as of FC5.  Only FC5 and
FC6 are currently fully supported; FC3 and FC4 are supported for security fixes
only.  If this bug occurs in FC3 or FC4 and is a security bug, please change the
product to Fedora Extras and the version to match.  If you can verify that the
bug exists in RHEL as well, please change the product and version appropriately.

The codebase for pirut and pup is quite different, but if a similar bug exists
in pirut and pup in FC5 or FC6, please change the product to pirut and the
version appropriately and update the bug report.

We apologize that the bug was not fixed before now.  The status will be changed
to NEEDINFO, and if the bug is not updated with evidence that it is a security
bug or a bug that affects RHEL, it will be closed.

Comment 3 John Thacker 2006-11-05 16:31:46 UTC
Closing per previous message.


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