yum error
Jim Cornette
fct-cornette at insight.rr.com
Wed May 18 00:12:36 UTC 2005
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?
More information about the test
mailing list