Re: [RFC] Interface for installing bootloaders

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

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=" ".

>         bbnote "No packages installed"
>         exit
>     fi
> 
>     sudo flock ${MOUNT_LOCKFILE} -c ' \
>         if ! grep -q ${BUILDCHROOT_DIR}/isar-apt /proc/mounts; then
>             mount --bind ${DEPLOY_DIR_APT}/${DISTRO} ${BUILDCHROOT_DIR}/isar-apt
>             mount --bind ${DL_DIR} ${BUILDCHROOT_DIR}/downloads
>             mount -t devtmpfs -o mode=0755,nosuid devtmpfs ${BUILDCHROOT_DIR}/dev
>             mount -t proc none ${BUILDCHROOT_DIR}/proc
>         fi'
> 
>     sudo chroot ${BUILDCHROOT_DIR} \
>         apt-get update \
>             -o Dir::Etc::sourcelist="sources.list.d/multistrap-isar-apt.list" \
>             -o Dir::Etc::sourceparts="-" \
>             -o APT::Get::List-Cleanup="0"
> 
>     sudo chroot ${BUILDCHROOT_DIR} \
>         apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -y \
>             --allow-unauthenticated install \
>             $PACKAGES
> }
> 
> addtask buildchroot_extra_install before do_rootfs

Thanks,
Jan