On 4/20/06, Richard Hally <rhally@xxxxxxxxxxxxxx> wrote: > I guess I'm looking at it differently. In Rawhide: > 1. Addon modules are built against a specific kernel. > 2. when a newer kernel is built in rawhide, the modules are not rebuilt > to match. > 3. the kernel that the modules matched has been replaced by the newer > kernel in rawhide. > At this point, where would I get the kernel and modules that match up? you have clearly missed the point of the bulk of the communication in this thread. Nothing you have just said is wrong, but you don't seem to be understanding the previous comments that Paul and I have made so far. And your question doesn't require yet another repository for this crap. You can move the addon kernel modules to Extras.. build them in Extras and then push them in Extras later in the day than rawhide is pushed.. none of which requires the existance of a customized kernel to be built...ever. Yes there is a mismatch between the modules and the kernel in rawhide. But that is strictly a result of the limitations associated with how rawhide is pushed and the technological limitations which prevent automaticlly triggered rebuilds of the kernel module packages on a kernel build inside the Core build system. As its been pointed out by Paul, the way Extras is pushed, there is a time differential between rawhide being available and the next Extras push which make it marginally easier for the modules to be rebuilt, manually, and be in sync again when Extras is pushed. Having yet another repository definition that includes both the addon modules AND a custom kernel only adds to the complexity of the situation it does not in fact solve any problems. -jef -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list