Bug 242368 - yum (as used by pirut) fails to install all dependencies
Summary: yum (as used by pirut) fails to install all dependencies
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 7
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
: 242748 243581 244379 245755 246787 248690 249221 251842 343771 (view as bug list)
Depends On:
Blocks: 246625
TreeView+ depends on / blocked
Reported: 2007-06-03 18:55 UTC by Tom Horsley
Modified: 2008-03-17 00:35 UTC (History)
15 users (show)

Fixed In Version: 1.3.9-1.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-10 22:24:58 UTC

Attachments (Terms of Use)
package-cleanup --problems output (5.29 KB, text/plain)
2007-06-03 18:55 UTC, Tom Horsley
no flags Details
bziped /var/log/messages from i386 installation (21.44 KB, application/octet-stream)
2007-06-04 21:53 UTC, Tom Horsley
no flags Details
bziped /var/log/yum.log file (1.78 KB, application/octet-stream)
2007-06-04 21:56 UTC, Tom Horsley
no flags Details
bziped /var/log/rpmpkgs file (11.10 KB, application/octet-stream)
2007-06-04 22:35 UTC, Tom Horsley
no flags Details
Clear Depsolve.deps (678 bytes, patch)
2007-06-27 09:11 UTC, Florian Festi
no flags Details | Diff

Description Tom Horsley 2007-06-03 18:55:23 UTC
Description of problem:

Vast numbers of dependencies are not installed.

This is exactly like bug 242279 except I was installing i386 and I used
pirut rather than yumex to download all the additional stuff I wanted
on my system.

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

How reproducible:

This is the 2nd time it happened.

Steps to Reproduce:
1. install fedora 7, add livna repo
2. run Add/Remove software
3. search for and select gobs of additional things you want installed
4. hit the "Apply" button.
Actual results:

Installs lots of stuff, but also misses lots of dependencies (see the
attached run of: package-cleanup --problems

Expected results:
should automatically download dependencies.

Additional info:
A lot of this was from the livna repo, but other parts are from the fedora
repo and it missed dependencies in both, so I don't think it is merely a
busted repo.

Since I've now seen the same bug happen with yumex and pirut, it seems
likely it is really some underlying yum issue, but I submit it against
pirut since that was the tool I was running.

Comment 1 Tom Horsley 2007-06-03 18:55:23 UTC
Created attachment 156028 [details]
package-cleanup --problems output

Comment 2 Tom Horsley 2007-06-03 22:24:09 UTC
It has been suggested I should change the category to yum (since this happened
on both pirut and yumex), so I'm doing that.

Just to add some additional info, I'd point out this wasn't an upgrade,
but a clean install from scratch. Some related discussion on the
fedora-list can be found starting here:


To me, the most relevant facts seem to be these:

I asked pirut (or yumex in my first bugzilla) to install some

It claimed to have installed them.

Yet package-cleanup --problems then shows there are missing
dependencies (as well as a manual rpm -q -R showing the dependencies
do indeed exist in the rpm).

A manual "yum install" of the missing dependencies is able to
find and install them using the same set of repos the
first install used.

Therefore, the rpms I requested did include valid dependencies,
the repos did include those dependent rpms, yet the installer
didn't install them.

Thus my conclusion there is a bug somewhere :-).

P.S. It did tell me it was installing some additional packages
to satisfy dependencies, so it didn't miss all of them, just some
of them.

Comment 3 David Timms 2007-06-04 11:31:05 UTC
Tom, would you be able to post the messages, yum log and the last two rpmlogs as
attachments {maybe bzip2'ed}.
/var/log/messages {and .1 if you installed before Sunday}
/var/log/yum.log  {"  "}
/var/log/rpmpkgs  {"  "}
What we should see in the yum log is where you were adding packages - we'll then
be able to see if it missed a cleanup process.

Comment 4 Tom Horsley 2007-06-04 13:05:09 UTC
I can't get to the logs till after work, but I'll attach them when I get home.
Meanwhile, I notice over in the fedora-list someone else had a problem with
pirut installing eclipse after a clean f7 install - same sort of missing
dependencies, so if you have a nice clean f7 laying around somewhere, it
might be simpler to reproduce by doing that than to wait for my (much more
complicated) logs.

Comment 5 Jeremy Katz 2007-06-04 20:11:30 UTC
Were you installing or updating packages that were already installed?

Comment 6 Tom Horsley 2007-06-04 21:46:29 UTC
This was definitely installing new stuff, not updates. The sequence
I went through was:

install all optional packages for all groups, except no virtualization
and none of the extra languages (since I can't read anything but english
anyway :-).

get notified there are updates after booting up, go ahead and install them.

install the livna-release-7.rpm from livna.org

Then run Add/Remove software (pirut) on my freshly genned system to get
a lot of additional stuff I use. Run it in search mode, and click on the
things it finds, then say "Apply". It was after this finished that
lots of dependencies were missing.

My notes for the stuff I want to install are a bit fuzzy, but here's
the list I search for:

hddtemp, gkrellm and hddtemp and themes plugins for gkrellm
mplayer, transcode, ffmpeg, vlc, etc.
   (add most anything searching for "dvd" finds to get dvd libs for
   decrypting, navigating, etc..
claws-mail & friends (claws plugins, bogofilter, etc)
lesstif & associated rpms

Now I'll go dig up those logs and add them as attachments.

Comment 7 Tom Horsley 2007-06-04 21:53:12 UTC
Created attachment 156138 [details]
bziped /var/log/messages from i386 installation

This is the messages log file from the i386 Fedora 7 installation. It hasn't
been up much since the install, so there is no messages.1 file yet.

Comment 8 Tom Horsley 2007-06-04 21:56:53 UTC
Created attachment 156140 [details]
bziped /var/log/yum.log file

This is the yum.log file from the same i386 F7 install. Note that there
are no missing packages on the system anymore because I manually installed
all the ones package-cleanup told me were missing via an extra run
of yum, but there should be a gap in the timestamps between the initial
install and the later manual install.

Cron hasn't had a chance to build the rpm package list yet. When I can get
booted over to the i386 system, I'll manually run the cron job and add the

Comment 9 Tom Horsley 2007-06-04 22:35:28 UTC
Created attachment 156144 [details]
bziped /var/log/rpmpkgs file

Manually ran the /etc/cron.daily.rpm script, here's the resulting
rpmpkgs list.

Comment 10 Tom Horsley 2007-06-04 22:42:15 UTC
Poking around in the yum.log file, I see this entry is the first
missing dependency I had to install, everything before this was from
the pirut run:

Jun 03 14:27:47 Installed: libXp.i386 1.0.0-8

I was trying to build a little motif app I have and it wouldn't link, but
libXp should have been dragged in by lesstif and/or lesstif-devel dependencies.

Anyway, once I realized that was missing I ran package-cleanup --problems and
created a list of missing dependencies to pass to yum install, and most
everything following the libXp entries was from that call to yum.

Comment 11 Jeremy Katz 2007-06-05 15:13:05 UTC
Hmmm... I might be on to something here.

When you did this in pirut, did you say okay and then cancel and go back and add
more stuff?  I've reproduced at least that way... now to find the root cause and
it's possible that it manifests in other cases too

Comment 12 Tom Horsley 2007-06-05 16:40:41 UTC
I don't remember doing that. What I mostly remember doing was putting in one
search term, hitting search button, selecting various items, then typing
a new search term in the field and hitting search again to select yet more
items. Perhaps constantly changing the search term is similar to OK/Cancel.

Comment 13 Jeremy Katz 2007-06-05 17:30:49 UTC
I don't think that changing the search term shouldn't trigger this, but it could
be manifesting oddly.  I'm building pirut-1.3.8 right now for the devel tree and
will be pushing it for F7-updates after a few days of sitting in rawhide.  If
you could try to reproduce with it, that would be good.  Since with the changes
in it, I can't reproduce a problem

Comment 14 Doncho Gunchev 2007-06-06 17:08:26 UTC
Could this be related/duplicate to/of bug # 242299? I tried this with
speedcrunch (needs qt4). With pirut-1.3.7-1.fc7 no deps are installed if I
cancel it the first time. With pirut-1.3.8-1.fc8 the deps are always shown, it's
ok but plain yum is still not (after transaction reset I can install speedcrunch
without qt4).

Comment 15 Tom Horsley 2007-06-06 20:59:36 UTC
You know, after reading bug 242299, my memory may be improving. It is possible
that I had some conflicts reported on my initial attempt to install, so I
removed one or two things from the install list and tried again. I seem to
recall lsdvd conflicting with something in one install and gallery2 conflicts
in the other. These may well be the same bugs.

Comment 16 Tim Lauridsen 2007-06-07 08:54:38 UTC
I look like it have something to do with cancel a already depsolved transaction
and adding/removing some packages and running a new depsolve.

If I do the following in yumex :
Add 'xfce-utils' to the queue and process it, then i got a confirmation dialog
with all the dependencies to 'xfce-utils', if i press 'Cancel' and go back to
the package list and add 'k3b' and process the queue again, i get a confirmation
dialog missing a lot of dependencies.

It look like there is some problems to clear, some of the datastructures in yum.
del self.ts & del self.tsInfo deletes the object, but some of sub object
declared inside the objects lives on.

I made a patch to yumex a couple of days ago where i had to do do the following
to avoid some strange error about 'can't work on a closed database'.
I had to do the following to avoid the errors.

   self.repos.repos =  {}
   del self.repos 

   del self.repos 

was not enough.

Comment 17 Pádraig Brady 2007-06-07 11:25:52 UTC
Same happened here.
I did a clean install.
Started pirut to select more packages
I got some error message I think about unsigned packages.
Went back and unselected unsigned packages: tkcvs, scons, notecase
Clicked "Apply".
Looks like all packages were installed without dependencies.

Comment 18 Jeremy Katz 2007-06-07 11:50:27 UTC
Okay, based on comments #15 and #17, this is fixed with pirut 1.3.8 and also
fixed better with yum 3.2.1.

Comment 19 Jeremy Katz 2007-06-13 17:59:28 UTC
*** Bug 243581 has been marked as a duplicate of this bug. ***

Comment 20 Thomas J. Baker 2007-06-14 13:26:31 UTC
I don't know if I should add here or start a new bug. This morning at home I
updated my desktop using sudo yum update which updated many things including the
kernel. Update ran fine, I rebooted and am running the new kernel. I used my
home mirror of fedora which is a mirror of my work mirror, i.e., they are in
sync, same files, etc. Got to work and tried to update my desktop there and the
update fails because the kernel needs new mkinitrd which doesn't seem to
available. I look at home and mkinitrd was not updated and yet the kernel was
updated. Both systems are running FC7 i386.

I just tried to update my laptop at work and it's going to install the new
kernel without installing the mkinitrd update. I just thought of one difference.
The system that is failing to update accesses the update data using a
file:///URI over nfs instead of an http:///URI. Both systems that use http://
don't require the mkinitrd update while the one that uses file:// does.

I have not yet updated the laptop and could hold off doing so for a while if you
wanted me to test something.

Comment 21 Michael Schwendt 2007-06-15 11:47:23 UTC
*** Bug 244379 has been marked as a duplicate of this bug. ***

Comment 22 Jeremy Katz 2007-06-26 22:30:10 UTC
*** Bug 245755 has been marked as a duplicate of this bug. ***

Comment 23 Florian Festi 2007-06-27 09:11:58 UTC
Created attachment 157986 [details]
Clear Depsolve.deps

This patch fixes the remaining problem about the outdated deps cache as
described in #245755.

Comment 24 Florian Festi 2007-06-27 09:18:45 UTC
Be aware that the above patch may (approximatly) double the run time of yum. And
although it fixes the problem for the pirut use case the cache can still get
outdated if tsInfo.remove() is called during .resolveDep() (doesn't happen yet)

Better solution would be to remove the cache completely and do caching at places
where the cache can be kept up2date or does not get invalidated at all.

Comment 25 Florian Festi 2007-07-23 11:08:48 UTC
*** Bug 249221 has been marked as a duplicate of this bug. ***

Comment 26 Fedora Update System 2007-07-23 18:50:20 UTC
pirut-1.3.9-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Andy Burns 2007-07-23 23:08:37 UTC
*** Bug 242748 has been marked as a duplicate of this bug. ***

Comment 28 Jason Farrell 2007-07-24 02:03:24 UTC
Yes - the problem persists with pirut-1.3.9-1.fc7

Still reproducable using the steps in my dupe bug report:

Comment 29 Jeremy Katz 2007-07-24 20:28:30 UTC
*** Bug 248690 has been marked as a duplicate of this bug. ***

Comment 30 Fedora Update System 2007-08-10 22:24:31 UTC
pirut-1.3.9-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 31 Matthias Saou 2007-08-12 14:52:59 UTC
*** Bug 251842 has been marked as a duplicate of this bug. ***

Comment 32 Marcin Zajaczkowski 2007-10-20 21:38:29 UTC
*** Bug 343771 has been marked as a duplicate of this bug. ***

Comment 33 Michael Schwendt 2008-03-17 00:35:30 UTC
*** Bug 246787 has been marked as a duplicate of this bug. ***

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