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
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.
Steps to Reproduce:
1.Use up2date to install a package
2.Use up2date to install another package
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.
A way to refresh indexes on an as-needed basis.
Internal RFE bug #120073 entered; will be considered for future releases.
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.
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