Bug 318041

Can you publish the output when you set installonly_limit to 0 and when you set
it to 2?

It would be helpful to see the output of yum -d5 for both of those operations.

Created attachment 220311 [details]
failure after confirmation

Well, things have changed a little. I was unforgivably careless and erased the
oldest kernel package, so now there's only one old kernel installed. This has
the effect that yum fails at the later point only when installonly_limit is 1.
When it's 0, 2 or 3 – or presumably any higher number – yum fails at the
earlier point. Apparently it gets through the dependency resolution phase only
if installonly_limit is a positive number less than or equal to the number of
installed kernel packages.

This attachment is what I get when installonly_limit is 1.

Created attachment 220321 [details]
failure during dependency resolution

And this is what I get when installonly_limit is some other number.

hmm, you're using 3.2.5 - could you grab 3.2.6 from updates-testing and retry,
please? I made some changes to the kernel ver detection in that one which I
think will help.

thanks

Created attachment 224681 [details]
yum-d5_3.2.6_limit_1_Linux_2.5.22.9

Do you detect the version of the running kernel? Then it might be significant
that my results in comment 2 were produced with Linux 2.6.22.9 running. I had
downloaded kernel-2.6.22.9-91.fc7 manually and installed it with RPM, bypassing
Yum. To test yum -d5 I removed that package (and by mistake the oldest one
too), but I didn't reboot.

This time I have tested both with 2.6.22.9 running and with 2.6.22.5 running,
in both cases with only the 2.6.22.5 package installed. Yum is version 3.2.6
from updates-testing.

Under the same circumstances as last time (Linux 2.6.22.9 running but not
installed), Yum 3.2.6 behaves exactly like Yum 3.2.5 did, but under the same
circumstances as when I first reported this bug (Linux 2.6.22.5 runing) it
fails during dependency resolution regardless of the value of
installonly_limit. This is an improvement, but of course not enough as I still
can't get it to install a new kernel.

The only other difference between Yum 3.2.5 and 3.2.6 that I noticed was that
when I ran yum remove kernel-2.6.22.9-91.fc7, Yum 3.2.6 correctly removed the
corresponding version of the ipw3945 driver. With Yum 3.2.5 I had to add that
to the command line.

I see that Yum first tries to find an "update path" for the driver's dependency
on the old kernel package, and then says "converted to install". It seems to do
things in the wrong order. I would think it should convert the kernel update to
installation *before* it tries to resolve dependencies on the old kernel.

Here's the output when installonly_limit is 1 under Linux 2.5.22.9.

Created attachment 224691 [details]
yum-d5_3.2.6_limit_1_Linux_2.5.22.5

And here's the output when installonly_limit is 1 under Linux 2.5.22.5, which
is identical to the output for other values of installonly_limit under both
kernels.

the dep resolution error is not related to this bug and is a red herring. It
looks like installonly_limit is doing the right thing under 3.2.6.

Please run the following for me:

yum list installed kernel\*
yum list available kernel\*
yum list updates

cat /etc/yum.conf | grep installonly
uname -a

thanks

# yum list installed kernel\*
Loading "refresh-updatesd" plugin
Installed Packages
kernel.x86_64                            2.6.22.5-76.fc7        installed       
kernel-devel.x86_64                      2.6.22.9-91.fc7        installed       
kernel-devel.x86_64                      2.6.22.5-76.fc7        installed       
kernel-headers.x86_64                    2.6.22.9-91.fc7        installed       
# yum list available kernel\*
Loading "refresh-updatesd" plugin
Available Packages
kernel.x86_64                            2.6.22.9-91.fc7        updates         
kernel-debug.x86_64                      2.6.22.9-91.fc7        updates         
kernel-debug-devel.x86_64                2.6.22.9-91.fc7        updates         
kernel-doc.noarch                        2.6.22.9-91.fc7        updates         
kernel-kdump.x86_64                      2.6.21-1.3194.fc7      fedora          
kernel-kdump-devel.x86_64                2.6.21-1.3194.fc7      fedora          
kernel-xen.x86_64                        2.6.20-2936.fc7        updates         
kernel-xen-2.6-doc.noarch                2.6.20-2936.fc7        updates         
kernel-xen-devel.x86_64                  2.6.20-2936.fc7        updates         
# yum list updates
Loading "refresh-updatesd" plugin
Updated Packages
antlr.x86_64                             2.7.7-1jpp.3.fc7.2     updates         
curl.i386                                7.16.4-1.fc7           updates         
curl.x86_64                              7.16.4-1.fc7           updates         
curl-devel.i386                          7.16.4-1.fc7           updates         
curl-devel.x86_64                        7.16.4-1.fc7           updates         
eclipse-cdt.x86_64                       1:3.1.2-8.fc7          updates         
hpijs.x86_64                             1:1.7.4a-6.fc7         updates         
hplip.x86_64                             1.7.4a-6.fc7           updates         
kdebluetooth.x86_64                      1.0-0.34.beta8.fc7     updates         
kernel.x86_64                            2.6.22.9-91.fc7        updates         
libsane-hpaio.x86_64                     1.7.4a-6.fc7           updates         
postgresql-libs.x86_64                   8.2.5-1.fc7            updates         
postgresql-libs.i386                     8.2.5-1.fc7            updates         
# cat /etc/yum.conf | grep installonly
installonly_limit=0
# uname -a
Linux dors.xn--rombobjrn-67a.se 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:08:59 EDT
2007 x86_64 x86_64 x86_64 GNU/Linux

Yum 3.2.6 is not doing the right thing. It fails to install kernel updates. If
the dependency resolution error is unrelated then what prevents Yum from
installing the update?

In case somebody out there cares about this problem, here's an interesting
observation: I have Yum 3.2.7 now, and I discovered by pure accident that Yum
fails to install kernel updates only when there is a driver package installed
for the latest kernel installed. If there are several kernel packages installed,
and driver packages are installed for older kernels but not for the latest
kernel that's installed, then Yum can successfully install a new kernel and
seems to obey installonly_limit.

I'm starting to think that this behavior is actually intended as some kind of
feature, and that the bug that remains in Yum 3.2.7 is only that the error
message is completely backwards and very misleading, but in that case I have to
wonder why Seth Vidal doesn't simply explain this.

1. yum doesn't run a transaction unless everything in the transaction has been
successfully dependency solved

2. If you are going to use (kmdl) kernel modules you have to use the
kernel-module plugin to make sure you get later ones installed/removed.

That's really what this comes down to.

yum install yum-kernel-module

and see if your problem gets better.

"yum doesn't run a transaction unless everything in the transaction has been
successfully dependency solved"

Neither does RPM. I have always assumed that the definition of "dependency" is
the same in Yum as in RPM. It seemed like a very reasonable assumption given
that the purpose of Yum is to resolve dependencies for RPM. But apparently the
definitions of "dependency" differ, because in this case Yum rejects a
transaction that RPM happily runs.

OK, so Yum tries to ensure that kernel modules get updated together with the
kernel. That's a good idea, but something must be done about the error message.
It says "Missing Dependency: X is needed by package Y". Normally that means that
Yum tried to install Y but X wasn't available. When both X and Y are already
installed the only way I can read it is that Yum tried to remove X. Therefore I
thought Yum ignored installonly_update and tried to remove old kernel packages.

When X is in the installonlypkgs list the message should instead be "Missing
co-update: An update to kernel won't be installed because there is no
corresponding update to Y."

"Missing Dependency: X is needed by package Y"
Can also mean that you cant update packet X to a new version, because packet Y
need the old version of X.
There is a lot of cases, so it is hard to give a message describing the cause of
why there is a missing dependency.
Another way to read it is.
If where do this Transaction then we will have a
"Missing Dependency: X is needed by package Y"
So this is why we don't do it, because we don't want to break your system. 

That's *exactly* what I thought it meant, and that's why I thought Yum ignored
installonly_update and tried to remove old kernel packages.

When X is in the installonlypkgs list, then Yum is *not* supposed to update X;
it's supposed to *install* the new version *without* removing the one that's
already installed. That Y needs the old X is then *not* a problem in itself,
because the old X *will still be there*. The dependency will *not* be missing.

If, on the other hand, X were to be updated the usual way, then the dependency
would be broken, and now yum says the dependency would be broken, so I draw the
conclusion that Yum tried to update X the usual way. That conclusion is wrong,
and therefore the message is wrong.

You say it's hard? Yes, writing programs of good quality is hard. If it were
easy there wouldn't be so many companies selling garbage and calling it software.

Björn,
 Your hostility to Tim is not necessary or warranted. We're trying to solve this
problem but it is not  a trivial issue to work with.

I ask that you test the behavior you're seeing on yum 3.2.12 from rawhide and
let us know if the problem persists. We've fixed a lot of problems since november.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping