Re: [RFC] Interface for installing bootloaders

[Claudius Heine <claudius.heine.ext@siemens.com>]

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.

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de