Bug 121216

Summary:	up2date uses too much memory, too slow
Product:	[Fedora] Fedora	Reporter:	Dimitri Papadopoulos <dimitri.papadopoulos>
Component:	up2date	Assignee:	Bret McMillan <bretm>
Status:	CLOSED CANTFIX	QA Contact:	Fanny Augustin <fmoquete>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	ahabig
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-10-29 14:31:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	120092

Description Dimitri Papadopoulos 2004-04-19 10:18:33 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040113

Description of problem:
I'm currently updating my FC2 test 2 machine. This is a Dell laptop
with 128 MB RAM and it takes hours to update this machine. It swaps
heavily.

It's Monday today and the laptop had been updated last Friday, but
there are nevertheless 113 packages to update. This probably won't
happen with regular Fedora or Red Hat releases, but I still think
up2date needs some optimisation.

# top
[...]
Mem:    256576k total,   254032k used,     2088k free    16092k buffers
[...]
 1920 root      15   0  109m  75m  27m S  6.3 30.2  12:11.60 up2date
[...]
# 


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


How reproducible:
Sometimes

Comment 1 Habig, Alec 2004-12-06 21:21:18 UTC

A possibly related issue: when one uses up2date to install a
previously not-installed package, it insists on downloading every
header file available during the "resolving dependencies" step.  This
takes a long time even here at the university on a darn good net -
it's got to be a show-stopper for people at home on dialups.  You
don't want things like this to prevent people from getting security
updates.

This is made worse by the fact that up2date itself doesn't handle
network timeouts very robustly, meaning that the whole thing is likely
to simply hang while trying to download those hundreds of headers.

Why does it need to know about every available rpm?  Certainly if I'm
trying to run down dependencies manually, I try to install the first
package, see what it wants, go grab the missing deps, try again, etc,
just following the dependency tree itself.  Surely up2date can do the
same, just downloading requested headers and following those trees.

All those headers waste an awful lot of space too, and could be
related to the memory usage question which started this bug.

Comment 2 John Thacker 2006-10-29 14:31:12 UTC

Note that FC1 and FC2 are no longer supported even by Fedora Legacy, and FC3 and
FC4 are supported by Fedora Legacy only for security issues.  Please retest this
bug against a still supported version and retest.  If this still occurs on FC3
or FC4 and is a security issue, please reopen the bug and assign it to that
version and Fedora Legacy.  If it occurs on RHEL, please change to that product
and the appropriate version.

Note that up2date has been replaced by pirut/pup for FC5 and FC6, the only
fully-supported versions of Fedora Core.  Please test pirut for software updates
and file bugs as appropriate.