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
next prev parent 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