Re: [RFC] Interface for installing bootloaders

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

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.

Jan

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