yum error

[Jim Cornette]

Jeff Spaleta wrote:
> On 5/17/05, Ivan Gyurdiev <ivg2 at cornell.edu> wrote:
> 
>>What safeguards are there to ensure that this does not happen in
>>Fedora-Updates, and why can't the same approach be applied to rawhide?
> 
> 
> As far as I know there are no inherent safeguards to prevent the
> standalone kernel module packages in core from becoming out of sync
> with the kernel updates.  I'm not aware of a technical solution that
> triggers a rebuild of the standalone kernel module packages when a
> kernel update is pushed.

This sounds like a great way to get these modules to match up w/ the 
installed kernel. Good luck to the wizard that can make this sort of 
solution happen.

   I fully expect a day or two lag sometimes
> even for updates.
> The standalone kernel module packages are very atypical packages
> because they must match the exact kernel build.. they aren't simple
> library-like dependancy chains.  But the way update tree operates will
> prevent the dependancy problem even if there is a couple days of lag
> between kernel and kernel-module package.  Note fc4 is the first Core
> release that is going to have stand-alone kernel module packages, and
> I expect the process to evolve over several release time scales.
> You'll also note that yum doesn't update these kernel module
> packages.. they are allways installed so you can have multiple
> versions installed just like the kernel.

Thanks for pointing this out relating to the stand-alone modules. I had 
over 5 versions of each for the modules that are causing the stir on 
this list (*-kernel). I only have three kernels installed.


> 
> If the kernel update lands in updates-testing first.. then this won't
..

> 
> Second of all.. rawhide tree doesn't cache old versions of packages...
> the updates tree do.
> In the fc4 updates it will be possible to see a kernel update without
> the associated kernel modules for it for a short time. What you will
> not see is the dep problem we are seeing now because the older kernel
> will also be available for a period of time, long enough for the
> kernel modules to be built against the new update kernel.  Practically
> speaking its going to be very difficult to get into a similar
> situation with broken kernel module packages deps in fc4 updates. If
> it ever happens in updates there is either a serious technical problem
> or someone is asleep at the wheel for like a month.
> 
> 
>>I think this behavior should be fixed, not documented.
> 
> 
> In a world with no perfect solutions...you learn to pick your battles.

It looks like we will have a lot of installed standalone modules for 
kernels that are no longer available. I deleted all of the prior 
versions prior to this query. The query will be very long once many 
standalone modules exist. This might be a battle worth supporting before 
it becomes a severe problem.

  rpm -qa |grep kernel
kernel-devel-2.6.11-1.1305_FC4
GFS-kernel-2.6.11.3-20050426.134031.FC4.9
kernel-2.6.11-1.1282_FC4
kernel-2.6.11-1.1312_FC4
gnbd-kernel-2.6.11.2-20050420.133124.FC4.10
kernel-devel-2.6.11-1.1312_FC4
dlm-kernel-2.6.11.3-20050425.154843.FC4.6
cman-kernel-2.6.11.3-20050425.154843.FC4.5
kernel-devel-2.6.11-1.1282_FC4
kernel-2.6.11-1.1305_FC4
kernel-doc-2.6.11-1.1312_FC4

Jim



> 
> -jef
> 


-- 
<change_m2> Will LINUX ever overtake sliced bread as the #1 achievement
             of mankind?