yum error

Jeff Spaleta jspaleta at gmail.com
Tue May 17 14:20:56 UTC 2005


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.  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.

If the kernel update lands in updates-testing first.. then this won't
be a problem because there will be a few days where the kernel module
packages to get built and pushed into updates-testing as well, and
then they can all be moved over to updates-released for general
consumption. The only people who notice will be the people who eat
updates-testing..and well..there are inherent risks associated with
updates-testing which are not dissimilar to rawhide risks.

But I fully expect there to be situations with some kernel updates
where the kernel update goes directly into updates-released because it
was deemed critical to do so. In this case I expect the standalone
kernel module packages to lag by a day.  But even then you will not
see the same problems you are seeing with rawhide right now with
regard to the kernel module packages deps because of how the updates
trees operate.

The updates tree is VERY different than the rawhide tree in several
important respects that affect how the stand-alone kernel module
packages. First of all.. rawhide churns very very fast. In the last
week(not including the weekend) there have been 4 or so kernel
updates.
Over the lifetime of the fc4 tree... the rate of change of updates is
going to be much slower..and much easier for the human maintainer of
the kernel module packages to stay well informed with each kernel
package update and push module packages reliably even without the help
of automation triggers.

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.

-jef




More information about the test mailing list