Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 107968
Summary: | up2date develops hdr file fetish | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fred New <fred.new2911> |
Component: | up2date | Assignee: | Adrian Likins <alikins> |
Status: | CLOSED DEFERRED | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | aleksey, maurizio.antillon, nitind, pb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-08-27 01:11:49 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: | 100644 |
Description
Fred New
2003-10-25 08:21:12 UTC
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. |