Re: [RFC] Interface for installing bootloaders

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

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

Cheers,
Claudius

-- 
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