From: Paulo Edgar Castro on
gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/761#note_44630...
ark/-/merge_requests/761#note_445670762>:
Brian Masney bmasney(a)redhat.com <mailto:bmasney@redhat.com> commented
via email:
|On Tue, Nov 10, 2020 at 06:03:48PM -0000, GitLab Bridge on behalf of
pecastro wrote: > From: pecastro on
gitlab.com > > `make prepare`
fails when trying to build external kernel modules. > Details in
https://bugzilla.redhat.com/show_bug.cgi?id=1882854 and > previous
related bugs. > > I'm not very happy with the final solution to this,
( the copy of the > tools dir ) but I ran out of steam chasing the
dependencies required to > make this work and at some point I started
doubting it was even possible > given that `make` seems to restart the
process rebuilding even some of > the binaries shipped. So it looks
like that'll add about 1.4MB to the kernel-devel package. I think
we're likely to run into this issue with other include files down the
road.|
||Is there a size requirement that should be honored? Surely
developer/debug time involved into making this work and maintaining it
going forward should be considered.
||
||I agree as I did above that the solution ( copying all of tools ) is a
bit blunt but ...
||
|||1.4MB in this day and age seems peanuts compared with the potential
time costs involved in the long run.
|
|Maybe an alternative approach would be to make the kernel-devel
package depend on the kernel-headers package and then setup symlinks
to the header directories.|
The kernel headers package includes "header files that specify the
interface between the Linux kernel and userspace"
Whereas the devel package "provides kernel headers and makefiles
sufficient to build modules against the kernel package"
Furthermore, most of the headers required for `make prepare` don't seem
part of the headers package and it would feel like an unnecessary mixing
of responsibilities ( in my opinion ) to make *devel* depend on
*headers* and go down a path of symlink kung fu ?
Maybe @Justin has a view on this ?
In any case, one or the other package would be getting a bit fatter ...
||