rawhide report: 20060420 changes

[Richard Hally]

Jeff Spaleta wrote:
> On 4/20/06, Richard Hally <rhally at mindspring.com> 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.
I think I have understood "the bulk of the communications in this 
thread". I also think you are making a mountain out of a mole hill.
KISS
When the modules are built (at any time, not under some time constraint) 
save a copy of the RPM of the kernel in the same location where the RPMs 
for the modules are saved.
Is that too simplistic for you?

> 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.
KISS (not marginally easier, much easier)
When the modules are built (at any time, not under some time constraint) 
save a copy of the RPM of the kernel in the same location where the RPMs 
for the modules are saved.

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

Never said any thing about "custom" kernel. Just save a copy of the RPM 
of the kernel that was used. Somewhere!

rh