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