Bug 203816 - new "kernel" component added during U4 update.
Summary: new "kernel" component added during U4 update.
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: libibverbs (Show other bugs)
(Show other bugs)
Version: 4.4
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Doug Ledford
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-23 20:32 UTC by Matthew Galgoci
Modified: 2007-11-17 01:14 UTC (History)
1 user (show)

Fixed In Version: openib-1.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-02 20:39:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matthew Galgoci 2006-08-23 20:32:18 UTC
Description of problem:

A new "kernel" component was added in rhel4u4 called "kernel-ib". This component 
matches against the default up2date exclude glob of kernel* but is required by
previously installed userland components.

The result of this is that an automated install that does an up2date -u after
installation requires a change in logic (and for most shops a manual
intervention) that breaks this automated updating via a kickstart %post or some
other automated method of applying updates (like rhn!).

Why was another kernel-* package introduced without concidering the
ramifications of the default up2date configuration? The naming of kernel-ib
is a very poor choice!

Here is what you get:

Testing package set / solving RPM inter-dependencies...
There was a package dependency problem. The message was:

Unresolvable chain of dependencies:
libibverbs  1.0.3-1                      requires kernel-ib
libmthca  1.0.2-1                        requires kernel-ib
libsdp  0.9.0-1                          requires kernel-ib

The following packages were added to your selection to satisfy dependencies:
Package                                Required by

[root@rhm1 ~]#

First, I don't even use infiniband on this system. I think the infiniband
userspace packages get pulled in by some default comps package selection.

Second, I would have expected a more sensible name for the userspace
infiniband packages than something that begins with kernel-*

Comment 1 Mike McLean 2006-08-28 17:46:05 UTC
Hmm, no openib component. Reassigning to libibverbs for the moment.

I suppose one could argue that the standard exclusion of kernel* is too broad.

I see a few options:
- Rename kernel-ib (a subpackage of openib) in U5
- Adjust the standard exclusion (possibly altering up2date to allow a more
robust specification).

Comment 2 Doug Ledford 2006-08-28 18:17:40 UTC
Well, first off, the kernel-ib name is from upstream.  While we don't ship
kernel modules in it, they do.  What we *do* ship in kernel-ib is all the
infrastructure around the kernel modules, like the udev rules file, the init
script that loads the right kernel modules based upon openib.conf, etc.

Second, saying that the kernel-ib name is a bad choice implies that I knew and
understood that listing kernel-* in the exclude portion of up2date not only kept
the kernel-* packages from being selected for upgrade/update/install on the
basis of themselves, but also kept them from getting pulled in to satisfy
dependencies, a situation I find to be just as poor of a choice as the kernel-ib
name.  Default it to off, that's fine, but when something is specifically called
out by other packages, failing to resolve the deps chain is a poor decision IMO.

My suggested fix would be a third option:

- Fix up2date to ignore packages in the excludes section for initial package
selection, but still consult the excluded packages as needed when resolving
dependency issues.

I think that may be more along the lines of what people would expect from
up2date, it's certainly what I would expect.  The current behavior is the
equivalent of saying "Oh, you want this excluded by default, OK, let me rm -f
those packages so you can't over ride that default should you wish to".

Comment 3 Mike McLean 2006-09-26 20:16:38 UTC
The third option suggested in comment #2 is definitely not what people expect
from up2date. If a sysadmin excludes a package in the up2date config and then
gets it anyway, they are going to be upset.

If there is strong opposition to renaming kernel-ib, then perhaps we can look
into changing the standard exclusion. I'm adding bretm to the cc list. Currently
we have:

Perhaps we could change it to:

Comment 4 Bret McMillan 2006-09-26 20:24:30 UTC
Something to consider for 4.6 is simply getting rid of kernel* from the
pkgSkipList as default.

It'd be a fairly big change in behavior, which makes it a little shaky for an
update release change, but I've felt for a long time excluding the kernel by
default seems wrong.

Comment 5 Doug Ledford 2006-09-26 20:36:52 UTC
Mike:  From my own experience, the excludes list should be as I said in comment
#2.  If you think people will really be that bothered by that option, then I
would suggest that there are two different points of view on this:

1)  A sysadmin trying to keep a package off his system at all costs and willing
to have major upgrades fail permanently if dependancy resolution can't be resolved

2)  A sysadmin who is just trying to avoid unnecessary downloads/installs and
keep the system as minimal as possible but accepts what is needed to satisfy the
dep chain on the things he has selected for install/update.

I can see both of those being legitimate, but currently up2date only caters to
one of those points of views.  Maybe, instead of just failing, it should list
the packages from the excluded list that are needed to satisfy the dep chain and
ask the user what they want, fail or use excluded packages.

Comment 6 Doug Ledford 2006-11-02 20:38:58 UTC
For all intents, this bug can be closed (whether the argued about issues are
resolved or not) since I renamed kernel-ib->openib for the base module.

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