public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Claudius Heine <claudius.heine.ext@siemens.com>
To: "[ext] Jan Kiszka" <jan.kiszka@siemens.com>,
	isar-users <isar-users@googlegroups.com>,
	Claudius Heine <ch@denx.de>,
	Henning Schild <henning.schild@siemens.com>,
	Andreas Reichel <Andreas.Reichel@tngtech.com>
Subject: Re: [RFC] Interface for installing bootloaders
Date: Tue, 4 Sep 2018 11:27:25 +0200	[thread overview]
Message-ID: <4ae0dc9d-7fa4-9fa0-7844-aab25579fdb7@siemens.com> (raw)
In-Reply-To: <0aeb9010-8fed-6094-ac12-41983c3831ae@siemens.com>

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

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.

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

[-- Attachment #2: buildchroot-depends.bbclass --]
[-- Type: text/plain, Size: 1459 bytes --]

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())}"

    if [ -z "$PACKAGES" ]; then
        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

  reply	other threads:[~2018-09-04  9:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04  7:17 Jan Kiszka
2018-09-04  9:27 ` Claudius Heine [this message]
2018-09-04  9:33   ` Jan Kiszka
2018-09-05  6:08   ` Jan Kiszka
2018-09-05  7:34     ` Claudius Heine
2018-09-05  7:47       ` Jan Kiszka
2018-09-05  7:57         ` Claudius Heine
2018-09-05  8:05           ` Jan Kiszka
2018-09-05  8:16             ` Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ae0dc9d-7fa4-9fa0-7844-aab25579fdb7@siemens.com \
    --to=claudius.heine.ext@siemens.com \
    --cc=Andreas.Reichel@tngtech.com \
    --cc=ch@denx.de \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox