Bug 107968

I forgot to mention that while up2date is in its seemingly infinite loop, it is
filling /var/spool/up2date with every hdr file in the world.

Another thing I left out:  I have changed my up2date sources file to access two
other Rawhide mirrors, but all the testing was done using the default yum source
at redhat.com.

Update:  I decided to see if up2date would run to completion, so I started the
graphical interface from Gnome.  After selecting to update librsvg2 and
librsvg2-devel, I monitored the contents of /var/spool/up2date.  After
downloading 850 header files (4 hours on my ADSL connection), the up2date window
updated itself with a new set of packages I could select to install.  But I
couldn't touch this window while the "Progress Dialog" window was still showing.
 No more header files were downloaded, so after a while I closed the progress
window by clicking on the X in the upper right corner.

Using my previous information about the missing dependencies, I selected
libcroco from the new menu, and clicked Forward.  All three packages (librsvg2,
librsvg2-devel and libcroco) installed successfully and up2date ended.  There
are still 847 .hdr files in /var/spool/up2date.  The last header file is for
httpd and it is dated Oct 25 15:22 (08:22 Eastern Daylight Time).

I was also experiencing this "hang" at dependency resolution as well.  Rather
than waiting the 4 hours, I un-selected the librsvg2 packages from the list, let
up2date complete (which it did in a normal amount of time), then manually
downloaded and updated the librsvg2 and libcroco packages.

Well, this is basically a dupe of bug 107921.  There are a few differences, but
I think the complaint about up2date's downloading of hdr files is a
misconception of how up2date works.  Up2date is supposed to download all of the
hdr files since that's how it gets the information on the package dependencies.
 The reason it's taking so long to download the hdr files is that the Redhat
server is too overloaded to be useful.  Use another mirror and this should go away.

Also. you don't need the "devel" version of the library.  This is only necessary
if you actually want to write progams that use the library.  Since it sounds
like you were just updating the installed binary version you don't need the devel.

4.1.11 or 4.1.12 should be faster...

I'd blow away /var/spool/up2date/rawhide-* though,
to make sure you get a new package list.

fedora up2date is using the yum protocol and metadata, which
requires that all headers be downloaded to solve deps. 

This issue just came up again with the most recent set of updates on 2003/10/28.
 After a process of elimination, it turned out that ntp was the problematic
package which caused up2date to hang at the "resolving dependencies" stage. 
After manually downloading ntp-4.2.0-1.i386.rpm, it turned out that the missing
dependency was libmd5.  After some searching on the web, I found out that this
library is provided by w3c-libwww-5.4.0-7.i386.rpm, so I downloaded this
manually, and they both installed fine using rpm.

The common thread seems to be that up2date hangs for a long time and downloads
1000+ headers only if a dependency must be satisfied by a new package that is
not already installed on the system.

I'm not sure how yum works, but this behavior is really problematic even with a
fast network connection and a fast mirror.  Even with a fast mirror, downloading
1000+ headers to satisfy a simple dependency on one package will make up2date
stall for an unacceptably long amount of time.  Combine this with the fact that
by default all users' up2date configuration is set to point to Red Hat, and this
behavior will lead to a lot of bug reports and unhappy users unless it is fixed.

Forgot to mention I was using the latest up2date 4.1.12, which still hangs
virtually indefinitely at the resolving dependencies stage under the above
conditions.

the "download every header to solve a dep" is the way yum works.
It's slow. It uses too much bandwidth. It uses too much diskspace.


But not much I can do about it at the moment. Were working on a new
protocol design with the yum folks, but it's still in the 
design phase. 

OK, I have looked at the Yum web site and I understand more about how yum works.
Since up2date uses yum we are going to have to download lots of headers, at
least for the time being.  It sounds good that the protocol design will be
changed to address these issues.

I realize you can't do anything about the hdr download problem at the moment,
but I do have a few suggestions that might help reduce confusion for users and
keep them from reaching for the ^C key when it appears that up2date has hung. 
The first suggestion is to post a meaningful dialog when up2date needs to
download headers for uninstalled packages such as:

"Downloading package information for uninstalled packages, this may take a long
time depending on how many headers have already been cached on your system."

At that point, you might want to consider having some sort of progress indicator
as the headers are downloaded, either a progress bar or the names of the headers
as they are retrieved.  You may also want to allow a "cancel" operation.
Currently, at the point where the headers are being downloaded, the entire GUI
is blocked and there is no progress indication for a very long time, which
creates the appearance that the program has hung.

Regards,
Dave

I have thought of another possible way to address this issue until the protocol
is improved.  The idea is, when the system is installed, to have the anaconda
installer install *all* of the distribution header files into
/var/spool/up2date, even for packages which were not installed on the system. 
Because the total number of packages that change over time is relatively low
(especially for a normal release), up2date should then only have to fetch
headers for packages that have changed since the system was installed,
eliminating the long wait to download 1000+ headers the first time an update
requires a package that is not already installed. All of the other headers will
have been effectively pre-cached.

Is this the correct place to post this idea, or should it be posted it as an
enhancement suggestion for anaconda?

Regards,
Dave

Note that currently up2date d/l's all headers for _all_ architectures.
The least you could do is make sure only the relevant architectures
are touched!

*** Bug 107921 has been marked as a duplicate of this bug. ***

I have this problem too. I left it running for over 8 hours with no
positive results.

When I was installing Core 2, I said to myself, "This is one thing
that I hope works!" but it's doesn't seem to.

Forgive me if I seem naive, but is this system supposed to do things
that apt and synaptic can't?

When I press the "Launch Up2date..." button, it doesn't do anything. I
can launch it manualy though.

I don't know what to do with this installation, now : (
(insert bellyaching comments here)

There is nowhere in the dialouges to insert additional
repository/sources. Is there any way to get this sqeaking along?

Thanks for working on Fedora,
BrendaEM

Marking CLOSED DEFERRED since this is an issue with the way yum
operates. alikins is working with the yum folks to develop a better
way of doing things yum-wise. Wish we had CANTFIX.