Re: [RFC] Interface for installing bootloaders

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

On 2018-09-05 09:57, Claudius Heine wrote:
> On 2018-09-05 09:47, Jan Kiszka wrote:
>> On 2018-09-05 09:34, Claudius Heine wrote:
>>> Hi Jan,
>>>
>>> On 2018-09-05 08:08, Jan Kiszka wrote:
>>>> On 2018-09-04 11:27, Claudius Heine wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 2018-09-04 09:17, [ext] Jan Kiszka wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> for installing a bootloader into an image, a number of packages 
>>>>>> have to be installed into the buildchroot. These can be prebuilt 
>>>>>> packages or packages we build via Isar. Currently, we only handle 
>>>>>> the case of WIC requiring prebuilt Debian packages, and that in a 
>>>>>> hacky way (no proper distro abstraction, unneeded installation of 
>>>>>> unused dependencies). This proposal aims at providing a more 
>>>>>> holistic solution:
>>>>>>
>>>>>> - Introduce new variables that express the two types of dependencies:
>>>>>>     - BOOTLOADER_PREBUILT
>>>>>>     - BOOTLOADER_CUSTOM
>>>>>>
>>>>>>    So there is no "WIC" in these, any imaging recipe can use them.
>>>>>>
>>>>>> - Imaging recipes (e.g. via classes/wic-img.bbclass) should
>>>>>>     - install all packages from BOOTLOADER_PREBUILT and 
>>>>>> BOOTLOADER_CUSTOM
>>>>>>       into the buildchroot
>>>>>>     - DEPEND on all recipes in BOOTLOADER_CUSTOM
>>>>>>
>>>>>> - Define some common dependencies in conf/distro/${DISTRO}.conf:
>>>>>>     - GRUB_PREBUILT
>>>>>>     - GRUB_PREBUILT_append_${DISTRO_ARCH}
>>>>>>     - SYSLINUX_PREBUILT
>>>>>>     - ...
>>>>>>
>>>>>>    Those variables can then be used to initialize 
>>>>>> BOOTLOADER_PREBUILT as
>>>>>>    needed and also replace those nasty BUILDCHROOT_PREINSTALL_WIC in
>>>>>>    buildchroot-target.bb.
>>>>>>
>>>>>> - Set BOOTLOADER_PREBUILT or BOOTLOADER_CUSTOM in the
>>>>>>    conf/machine/${MACHINE}.conf or some overriding conf file - 
>>>>>> basically
>>>>>>    the same one that selects IMAGE_TYPE and WKS_FILE.
>>>>>>
>>>>>> Anything I missed? Better suggestions? Eventually, when we can 
>>>>>> derive bitbake recipe dependencies automatically from package 
>>>>>> dependencies, PREBUILT and CUSTOM could be folded together. Right 
>>>>>> now, we need that split.
>>>>>>
>>>>>> Jan
>>>>>
>>>>> I have a class that I use for the current project that allows 
>>>>> installing additional packages into the buildchroot from within the 
>>>>> image. I didn't had time to prepare patches for it for mainline 
>>>>> isar. But maybe that goes into to right direction.
>>>>>
>>>>> I attached it.
>>>>
>>>> ...
>>>>
>>>>> BUILDCHROOT_EXTRA_INSTALL ??= ""
>>>>>
>>>>> MOUNT_LOCKFILE = "${BUILDCHROOT_DIR}/mount.lock"
>>>>>
>>>>> BUILDCHROOT_DIR ??= "${BUILDCHROOT_TARGET_DIR}"
>>>>> BUILDCHROOT_BUILD_DEP ??= "buildchroot-target:do_build"
>>>>>
>>>>> do_buildchroot_extra_install[depends] = "${BUILDCHROOT_BUILD_DEP}"
>>>>> do_buildchroot_extra_install[deptask] = "do_deploy_deb"
>>>>> do_buildchroot_extra_install[stamp-extra-info] = 
>>>>> "${DISTRO}-${MACHINE}"
>>>>> do_buildchroot_extra_install() {
>>>>>     PACKAGES="${@" ".join(d.getVar("BUILDCHROOT_EXTRA_INSTALL", 
>>>>> True).split())}"
>>>>>
>>>>
>>>> Can you explain the magic dance in the line above? I don't see its 
>>>> need yet.
>>>>
>>>>>     if [ -z "$PACKAGES" ]; then
>>>>
>>>> ...provided you do "[ -z $VAR ]" here to catch VAR=" ".
>>>
>>> In sh i get:
>>>
>>>    $ tets="asdf asdf  asdf asdf"
>>>    $ [ -z $tets ] && echo yes
>>>    sh: 2: [: asdf: unexpected operator
>>
>> Ah, that's what I missed. But then we want to .strip() the variable 
>> for testing, rather than split/rejoin.
> 
> Might work, but I don't like having possible '\n' and '\t' in between 
> package names. (Ok, '\n' might not be an issue, since I think bitbake 
> already escapes that.)
> 
> For me that is the normal code snippet to convert bitbake 'arrays' into 
> shell strings.

I find this pattern in pure form in exactly one poky recipe. Therefore 
I'm not sure we need it in order to make a list built under bitbake in 
various ways available as parameter string for a shell command. Let's see...

Jan

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