From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6591699875972251648 X-Received: by 2002:a50:8879:: with SMTP id c54-v6mr3774176edc.1.1534967548834; Wed, 22 Aug 2018 12:52:28 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:add4:: with SMTP id b20-v6ls1233905edd.7.gmail; Wed, 22 Aug 2018 12:52:28 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzd+h8oQcpIVyhV73LNblFCQqGh5Mcuemmr7QtzMokFzmhdqQoHZxp0qMgHjBiUcRHpQ/LU X-Received: by 2002:aa7:c510:: with SMTP id o16-v6mr3630621edq.7.1534967548276; Wed, 22 Aug 2018 12:52:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534967548; cv=none; d=google.com; s=arc-20160816; b=AdB4Tuf2PaumqMIF0+VMmif7hpYlAbD7JRN/lkxuUCnA/pYYPFFsUHWEw21y/ZBTVv Sj4/SrJSta+c8ptvGM3yoGTTeY4abhgkdwUsDlkl4kWieNdEhVIabtqVq2okj4fqM2nI +SBHPzcZRohiwgFp7v8Osf6sQirs0MaWKOZrleAU3fF+Z17xJG1YNhkdvaUkVRiAVddq ewj57FEoQuvHfnqvqD8R4PnaiCOAvUPEtZJ0JvKlRkxmQnDTF+mu/81dKwQp5WPedrcA ROb5YgAIpd0TxTkx0x70v6NnzZKwgJLM9PEHOiMnn6AKg5Vtn5YEKi7oEdaUKxLlnsKA MUnQ== 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:references:to:from:subject :arc-authentication-results; bh=W98EzXiwMrjElvR54k3n8MyMsiIabmWi6XbB17STbTo=; b=U5ikM3tpYXuZ5q9u/M8EJvpT/eTNFQhpnEalu36HFht3VD7N1XuyPm2Mkk2b4WpUNj QtUZyzPrMFeOkDf5bPJ8A65r4pi4BCRqzvwl+7PbTD2Sq70BbTHM7Ogn4BWVXsLNk3Ir 6ei318Uadg6gVo3mul407BtSO6R0DVLSXZyAzrz+UTs45EZ6+hrVZhpABuZgLgEcF3BO 2I75a103U+ZKokZ7FMulSET0ZUbUct0e8bBZu1k4rLL7Z6vjfzvRH3CZUV01uCtvJZdK VFgmjb2S8Ex5DCtMOQJswMgbnwDUJKJlVUIHYF0s5dCwE7aZlpZfbSAejrSiqTc9ryW6 Yarw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id o55-v6si150440edo.3.2018.08.22.12.52.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 12:52:28 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w7MJqR8K010795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Aug 2018 21:52:27 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w7MJqR5V004670; Wed, 22 Aug 2018 21:52:27 +0200 Subject: Re: Minimizing isar-image-base From: Jan Kiszka To: Alexander Smirnov , isar-users , Christian Storm References: <0228b199-d672-6610-0180-c8a84542366c@siemens.com> <4db9adeb-b649-2d51-0e91-28d781297cf3@siemens.com> Message-ID: <2732c10e-93ff-bc63-dac6-707930ba89f8@siemens.com> Date: Wed, 22 Aug 2018 21:52:26 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <4db9adeb-b649-2d51-0e91-28d781297cf3@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: mlPrUApTF22H On 2018-08-22 16:37, [ext] Jan Kiszka wrote: >>> - Why do we pre-install dbus? >>> >> >> Again, IIRC, without dbus there was dirty boot log in QEMU, some >> services failed to start. > > I'll recheck that with stretch. Removed it, but I'm not seeing any error messages nor does systemctl report failed services. Maybe the bug was solved in stretch. Christian, you said there is a harder dependency in reality than the "recommends" as Debian declares now. Any comments on this? If it is really no longer needed, we could push the dbus dependency into debian-jessie.conf. Is raspbian-jessie on systemd as well? Then there as well. > >> >>> - Can we make apt optional? Installing it as transient package by >>>    default, e.g. What would happen if a downstream image then puts it >>>    into PREINSTALL again? Should we filter IMAGE_TRANSIENT_PACKAGES >>>    against IMAGE_PREINSTALL? >> >> I could suppose how apt went to isar-image-base recipe, initially it >> was a copy of buildchroot one. So nobody actually cares about the list >> of packages, there was only one requirement - no error and warnings >> during image boot in QEMU. >> >> In buildchroot apt is needed to populate the dependencies. >> >> With current Isar implementation the apt is a must package for image. >> Let me explain why. Below is the whole chain to generate image: >> >> 1. At first, isar-debootstrap is called. This recipe fetches minimal >> *pure* Debian suite for specified architecture. It's stored in >> tmp/deploy folder. >> 2. Image generation is started from copying this pre-fetched suite to >> work folder. >> 3. Then you chroot to this *pure* minimal suite. >> 4. And finally all the additional packages in pre-install list are >> installed via apt-get. >> >> So, the only way for current architecture - remove apt in post-build >> task. > > Right, this is what I had in mind. I think we already have the tooling > for that, don't we? We don't. IMAGE_TRANSIENT_PACKAGES is not suited. Also, apt seems to get installed via debootstrap anyway. We should be fine removing it as explicit IMAGE_PREINSTALL entry. I'll propose a patch. But we will need some explicit purging step that removes it again (and possibly more packages) after the image is done. And it should be under custom-image control, whether that step is run or not - or what the purge list contains. We could also use --exclude of debootstrap but that would imply forking the base bootstrap environment because we use the same for image and buildchroots so far. Probably not a good idea. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux