| Message ID | 20260813164500.3092151-1-felix.moessbauer@siemens.com |
|---|---|
| Headers | show |
| Series | Fix single-name single-content rule for kernel packages | expand |
On 13.08.26 19:45, Jan Kiszka wrote: > On 13.08.26 18:44, Felix Moessbauer wrote: >> Similar to upstream Debian, our kernel source packages are architecture >> specific. By that, we also have to encode the architecture (or machine) >> in the name of the package. Otherwise existing packages might get >> reused on rebuilds with other targets (or multiarch) >> >> In isar, this has ever been modeled incorrectly (the kernels .dsc file >> was arch=any despite being arch specific). This is easy to fix, but >> also depending on the kernels was done incorrectly (a KERNEL_NAME = >> mainline is not specific enough, as mainline on arm64 is technically a >> different kernel (source package) than mainline on amd64. >> > > It is more complicated than this: > > A source packages becomes architecture or even machine-specific if we > bundle the concretely built config file with it. If KERNEL_DEFCONFIG is > empty (default), a kernel source package is actually buildable for any > architecture, thus remains generic. Correction: KERNEL_DEFCONFIG can even be set. The question is whether we have a conditionally added external config file, and that condition depends on the architecture or machine. Only that latter step makes the source package arch or machine-specific. And that is a recipe author decision... Jan > > Now, if the user of our linux-kernel class decides to add a specific > config to the sources, it is now the the question how generic that > config is: only specific to the currently built architecture or even > specific to the selected machine? It is misleading to say, though, that > a source package which carries a machine-specific config is only > arch-specific. It's machine-specific. But hardly anyone would try to > build such a kernel for incompatible machines or even for a different > architectures. > > Theoretically, we could even stick multiple configs into the source > package, e.g. the whole cip-kernel-config repo, and select the one used > for a particular target build based on DISTRO_ARCH. That would resolve > the source package issue for such kernels as well. > > But I suspect it would still not help us with the native kbuild packages > if they have dependencies on the specific config. Then they would need > to carry the DISTRO_ARCH (the config selector) in their names. Would be > interesting to understand if that already bits us today with the > KERNEL_DEFCONFIG="" case. Did you check? > > Jan >
On 13.08.26 19:50, Jan Kiszka wrote: > On 13.08.26 19:45, Jan Kiszka wrote: >> On 13.08.26 18:44, Felix Moessbauer wrote: >>> Similar to upstream Debian, our kernel source packages are architecture >>> specific. By that, we also have to encode the architecture (or machine) >>> in the name of the package. Otherwise existing packages might get >>> reused on rebuilds with other targets (or multiarch) >>> >>> In isar, this has ever been modeled incorrectly (the kernels .dsc file >>> was arch=any despite being arch specific). This is easy to fix, but >>> also depending on the kernels was done incorrectly (a KERNEL_NAME = >>> mainline is not specific enough, as mainline on arm64 is technically a >>> different kernel (source package) than mainline on amd64. >>> >> >> It is more complicated than this: >> >> A source packages becomes architecture or even machine-specific if we >> bundle the concretely built config file with it. If KERNEL_DEFCONFIG is >> empty (default), a kernel source package is actually buildable for any >> architecture, thus remains generic. > > Correction: KERNEL_DEFCONFIG can even be set. The question is whether we > have a conditionally added external config file, and that condition > depends on the architecture or machine. Only that latter step makes the > source package arch or machine-specific. And that is a recipe author > decision... > Wait - it's actually arch or machine specific templating that bites us here: If KERNEL_DEFCONFIG or any other bitbake variable that influences the source package content (including the debian/ folder) if differing across builds while having the same name for the source package, that will obviously cause a mess. This is also where the CIP kernel from isar-cip-core gets different source-wise although it has identical configs on board. So, the better solution for such multi-purpose kernels is to introduce build-time config selection, rather than templating. Jan