Jeff Spaleta wrote:
On 5/17/05, Ivan Gyurdiev <ivg2@xxxxxxxxxxx> 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?