opencomputeproject
Pack kernel headers in separate package
With this series we make abstract kernel headers and other build artifacts required for third-party kernel modules build from onl-kernel package to separate package.
Later this onl-kernel-
See individual commit message for details on each change within series.
@sergeypopovich-ord We already have a separate kernel-mbuild package built for each kernel that is used in the exact way you describe in your pull request for all OOT module builds (including the BRCM BDE modules).
Before I review your request can you give me some background on what you are improving here or what problem you experienced with the existing mbuild packages?
If I'm right then headers isn't packed separately currently (I did this with my patch 3c03c8b ) and all mbuild stuff shipped with kernel package in /mbuilds directory under lib.
Main goal of this series is to unify ARCH naming between YAML and Makefiles and pack kernel headers as separate deb package.
My intend is to put headers, Kconfig files and other stuff with correct timestamps etc. separately from kernel binaries. This is how most major distros does things: separate binary kernel image/modules from headers. Final package becomes much more smaller.
All artifacts configuration improvements come from Debian/CentOS.
By treewide change unifying ARCH naming schema I just simplify things by removing extra suffix :amd64 from kernel versions and prepend it yaml when appropriate.
@sergeypopovich-ord Are you expecting to install the kernel headers/mbuild tree onto the target itself so you can compile OOT modules on the target (like a "normal" distro)?
The current kernel packages are only used by the build system - they aren't designed to be installed in the target filesystem (which is probably what you're doing and finding it cumbersome).
Adding the mbuild package to the target RFS for OOT builds on the target might get tricky because we don't strictly track the version of the running kernel against the matching package.
I have no issue with having a "regular" separation for this infrastructure but we might have to start versioning the running kernel properly. Please advise on your intended usage?
You are right. I'm planning to install mbuild headers package on target and use DKMS to build required OOT modules.