From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7016230395466219520 X-Received: by 2002:adf:a194:: with SMTP id u20mr41477664wru.275.1634137744147; Wed, 13 Oct 2021 08:09:04 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6141:: with SMTP id y1ls3438616wrt.3.gmail; Wed, 13 Oct 2021 08:09:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxS/ZkWRyBr62QdQEEbea9Ra4osYBP71Q+2WSsae+2S3VYAW9L4LlnavMSZaixlqxh3KICl X-Received: by 2002:a5d:4481:: with SMTP id j1mr41891836wrq.6.1634137743109; Wed, 13 Oct 2021 08:09:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634137743; cv=none; d=google.com; s=arc-20160816; b=h7fmuaH2De2JF7eKraVVyPlBtdn3bgNqdP+jgqEeJ4+SgdZUILSoKs07hVKleDBH5r Ow07febYRpnxJfw/Qf/os+dw427E3Yp9tTE9seZYa5JpLl2ebeIobFXnAUXwzCNpN5v9 rcBEhb901yrayNAwypQly1NLTJ84OcuZarZnWSEWfSepI+lAsYL0UJN0vFJTSOPkXLNe doY9vI+092tJMVmjhYvYXnxWJhLu95GryDjtqD19vDBYbj1QtiFDrL1homOftNe8q1TU 2Py2i+QyVHvVkCrdnYCxlUpoUK3qnKV3L8ccVMqEwZNgXjfB2pifLh7tolQKwcbdoAUb XLfA== 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=cHDjeabirTxAFN/OXSIEVxLNgNWDgFk7VLq3AE1PGMI=; b=iHggyB6GKWjBJGzbdOvKajUjjfbh7X/IdKuftEbVzX/HTcoQmLQCzp1bu+b8cZc7aG S08+9KUVxpn8ew9VkOTjCPJx7MtP510IK8s5pOddMJ7ZZTXOaiDXcPOa/PM/vRj913hC X3ILUOWPcbJISNhuPbGw1sSikMDZrDrBkWN2wKBrroDnCrGjuRvqesz+q1KMu4QNWV/X fpPqwEJ0KZewxEB4xfHSoDe4SvE1gh9SG6L5cEuSHPOJ53nAAH8/y8Bgc8ZkpPqLkqZG bqS5f3KL+zkt/rj5R2l8XUaqKt3ayAOHOebLtURl3Ec8EJemYYiy4W4HwIA20mkF6PAx iqUw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id g8si986418wrh.0.2021.10.13.08.09.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Oct 2021 08:09:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 19DF92lq017788 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Oct 2021 17:09:02 +0200 Received: from [167.87.2.42] ([167.87.2.42]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 19DF92fY027770; Wed, 13 Oct 2021 17:09:02 +0200 Subject: Re: [PATCH v2 03/10] rootfs: recursively depend on packages To: "Schmidt, Adriaan (T RDA IOT SES-DE)" , "isar-users@googlegroups.com" References: <20211012123625.1703627-1-adriaan.schmidt@siemens.com> <20211012123625.1703627-4-adriaan.schmidt@siemens.com> From: Jan Kiszka Message-ID: Date: Wed, 13 Oct 2021 17:09:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: yyWZ4Pvkk2RO On 13.10.21 16:43, Schmidt, Adriaan (T RDA IOT SES-DE) wrote: >> On 12.10.21 14:36, Adriaan Schmidt wrote: >>> This fixes a bug. >>> So far, this only worked when the dependency-of-dependency packages >>> were in isar-apt because they were just built. This explicitly >>> enforces do_deploy_deb on *all* dependencies. >> >> More curiosity: I'm not yet understanding the error scenario. A rootfs >> depends on a package recipe A, and that means on the completion of that >> recipe's do_deploy_deb task. If that recipe A depends on another package >> recipe B that one needs to be in isar-apt, thus has to finish its >> do_deploy_deb as well. But why could A have finished its build when B didn't >> even run do_deploy_deb yet? If A depends on B, it also depends on B's >> do_deploy_deb task, no? > > The rootfs depends on A's do_deploy_deb, but only A's do_prepare_build depends on B's do_deploy_deb. > If we can produce A (do_deploy_deb) from cache without running its do_prepare_build, then B might not be there (which is exactly what happened to me). > OK, this issue only surfaces once you introduce caching. Without caching, it's impossible to complete do_deploy_deb (or do_prepare_build) without all dependencies' do_deploy_deb. > Thinking about it I'm wondering if the same thing can happen when building a package, and if actually also do_prepare_build in dpkg-base needs to define recrdeptask instead of its current `do_prepare_build[deptask] = "do_deploy_deb"`? Conceptually, yes, same scenario, just different root. How does OE handle such cases? I bet there can be more. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux