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-*
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).
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".
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: pkgSkipList=kernel*; Perhaps we could change it to: pkgSkipList=kernel;kernel*-devel;kernel-smp;kernel-hugemem;kernel-largesmp;
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.
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.
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.