Re: rawhide report: 20060420 changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Spaleta wrote:
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.
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

--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]