Bug 119662 - RFE: Make up2date refresh list of available packages more intelligently
Summary: RFE: Make up2date refresh list of available packages more intelligently
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date   
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-01 06:58 UTC by Mike MacCana
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-13 01:13:41 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 Mike MacCana 2004-04-01 06:58:25 UTC
Description of problem:
With many of the changes in recent versions of up2date, its becoming
more useful as a generic package installation tool. Unlike rpm, it
allows customers to resolve dependencies from the network, query
dependencies for custom and third party apps, resolve dependencies
from local and remote repositories, and more. As I'm sure you know.
I'm an RHCX and have a lot of customer contact: they all *really* like
the tool.

One thing that's stopping up2date becoming Really Useful is that it
insists on refreshing indexes every time its run. I can understand the
need to make sure clients aren't using old index files when they
update their systems, especially for security updates, but when you're
performing a whole bunch of operations using up2date, you don't want
to refresh the list of available packages each time you ran the
command (this is particularly noticable in countries without local RHN
mirrors where this operation can take a very long time).

A possible solution could lie in the following:
* The addition of a 'refresh' argument to up2date to get information
on new packages.
* Using the RHNSd application - which, from what I've read, polls RHN
  every two hours - to force up2date to refresh when it is next run.

But you might have a better idea.

How reproducible:

Steps to Reproduce:
1.Use up2date to install a package
2.Use up2date to install another package
Actual results:
The indexes are downloaded twice, though it might have only been
seconds since they were last downloaded. This makes up2date slow and
puts unecessary load on the repository servers.

Expected results:
A way to refresh indexes on an as-needed basis.

Comment 1 Suzanne Hillman 2004-04-05 20:12:11 UTC
Internal RFE bug #120073 entered; will be considered for future releases.

Comment 2 Adrian Likins 2004-04-12 20:10:49 UTC
I don't really like this idea.

For starters, up2date only updates the indexes when
something has actually changed (either via channel
timestamp info from login for RHN use, or via
If-Last-Modified calls for yum/apt). dir
repos are admittedly kind of dumb in this regard

Note that while the user interface may indicate
that it is fetching this info, "fetching"
includes getting it from a local cache.

So adding a manual apt style refresh/update seems
like a bad idea to me. It seems like it would just
lead to users trying to work with data that is
old and incorrect. 

Comment 3 Mike MacCana 2004-04-13 01:13:41 UTC
Thanks for your reply Adrian. 

<i>For starters, up2date only updates the indexes when
something has actually changed ... "fetching"
includes getting it from a local cache.</i>

Ah - I wasn't aware of that. That's precisely the behavior I was
asking for. 


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