Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2018-01-30 12:06, Alexander Smirnov wrote:
> On 01/30/2018 01:52 PM, Jan Kiszka wrote:
>> On 2018-01-30 11:49, Alexander Smirnov wrote:
>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> This simplifies the common task of using a custom kernel instead of the
>>>> pre-selected debian variant: Move the kernel installation into a dummy
>>>> dpkg-raw recipe that only has the kernel package as dependency.
>>>>
>>>> Which recipe is used for providing the kernel can now be selected via
>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE.
>>>>
>>>> The kernel package name is communicated from the target multiconfig
>>>> file
>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable.
>>>
>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y
>>> support only official Debian kernel. For example Isar already supports
>>> Raspbian which contains its own Raspbian kernel.
>>
>> I'm always open for better name proposals.
> 
> So, if no reasons, I'd propose:
>  - KERNEL_PACKAGE
>  - KERNEL_PACKAGE_NAME
> 
> 
> [...]
> 
> 
>>>> +inherit dpkg-raw
>>>
>>> Do I understand correctly, that this recipe creates fake package that
>>> has dependency from the upstream kernel? So in target rootfs 2 kernel
>>> packages will be installed?
>>
>> Right, one empty linux-debian meta package and the real one. The former
>> allows us to trivially kick out the latter in favor of a custom kernel.
>>
> 
> What is the benefit of this complexity?

It's not complexity, it's simplification and cleanup over the current
hard-coding approach.

> If we need to have over-writable
> kernel name, it would be enough to pass current DEBIAN_KERNEL variable
> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar
> tree and no pseudo package in target rootfs.

There are several disadvantages with your approach:
- you need to encode the concrete package name instead of just defining
  an abstracting provider
- you need the same thing for linux-headers (which I'm currently very
  interested in as I need to build against the kernel)
- it deviates from the bitbake pattern of PREFERRED_PROVIDER

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux