From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6597265115990458368 X-Received: by 2002:a5d:64d2:: with SMTP id y18-v6mr3070929wrv.17.1536134258678; Wed, 05 Sep 2018 00:57:38 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:7705:: with SMTP id t5-v6ls302524wmi.8.canary-gmail; Wed, 05 Sep 2018 00:57:38 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYF9Q8qlDey1+5DKYY61I6P7YUZbB2rrfUmXhg/eksWvXhcZMsRetbjo9QHtOhw61+iLwsX X-Received: by 2002:a1c:ae53:: with SMTP id x80-v6mr1587211wme.29.1536134258274; Wed, 05 Sep 2018 00:57:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536134258; cv=none; d=google.com; s=arc-20160816; b=f+QWX7IQUpt+hOujyDA3vhoI+UF0D/a3iRNM6bZ4TDsr9IaFHWgtR06rJGoPuwXjng XCvwOASzYw0Xdr1z+SGIuE+BEA6BSs8VjqBw79RDxT69hqkY+h1EMlVHvjEsqzHjgK08 aLwLwBH7vRaFUH5KiM3uYUZFdrzCNR1ILuly97Pkgzu9CaVwYHLUsZReAkvfFVugumlE Til8D3OiWbDnQ9bhuCLCSJxVOKbOQJSrcDeAKXYANx4IAoFhCyjtoOE8qFidvoETo5oe Etnn4wcWGlnYJJ+PnjR5NfQvhN+mojWDmBwo3jxnClG9WGEnbIkllMWik+hoQmmwVPha QswA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=oBcVMNPfxqtfT1GgjU0PihZ1lkt3lSaFv91j+fwFr60=; b=miqbuN2UsksBYjMPPG2nvqbZrHQJ+N7WRU998M+3F5qHiFEzFcNQj6Ynjf/lWvDfeR plOskaWJ4VksFwwFLGEIxD/lrd/b4ISgSkmHzOq+2yoJK5XP/fZikDQxnT3foDbhdsZH 6TqroQNUpYWRlDUawMKlDV5EO2Lm9/OGBq/DfeQiG4uEZN+S2nVEHZsX55QEURynlg9T SQojHZLq171JNaZuyjYwK8lhVpmxmHKazObSAP5J0kmZ4pxmx8U0QHn2FEUgOmpZYFry GTOIW0ZPQdwUopRTElJvBdbi8noRcTe35ELQLp+7GS4Cw2hWhzCVoiRdcgUvGZC9km8o R/tA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id v18-v6si55741wmc.1.2018.09.05.00.57.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 00:57:38 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id w857vbgx014762 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Sep 2018 09:57:37 +0200 Received: from [139.25.69.181] (linux-ses-ext02.ppmd.siemens.net [139.25.69.181]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w857vb4e025702; Wed, 5 Sep 2018 09:57:37 +0200 Subject: Re: [RFC] Interface for installing bootloaders To: Jan Kiszka , isar-users , Claudius Heine , Henning Schild , Andreas Reichel References: <0aeb9010-8fed-6094-ac12-41983c3831ae@siemens.com> <4ae0dc9d-7fa4-9fa0-7844-aab25579fdb7@siemens.com> <11e15a42-0fa6-cda7-c9c0-4c60ea2b551c@siemens.com> From: Claudius Heine Message-ID: Date: Wed, 5 Sep 2018 09:57:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: VCR1oy8JhwTI 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