From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7016230395466219520 X-Received: by 2002:a05:6512:952:: with SMTP id u18mr40449424lft.516.1634140895863; Wed, 13 Oct 2021 09:01:35 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:3f14:: with SMTP id y20ls1272077lfa.1.gmail; Wed, 13 Oct 2021 09:01:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLJXlIfDffrCIFvA+bYJPv697XU9oSKpgBEUXbmvt2Owuru2gpFfp38Vp5wCudyqZ/Einz X-Received: by 2002:a19:dc08:: with SMTP id t8mr10883861lfg.100.1634140893165; Wed, 13 Oct 2021 09:01:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634140893; cv=none; d=google.com; s=arc-20160816; b=p1oye2W8oCpsqYHn4zMa4GQSKDZADQsI9HHdOfSwcLbe3wph/zGXYIMPHYs9V6qUoj mbHWV8k5xEwFJLdkfh+pao1iqXalow11GPixDjLt9vDx3I6TF5jquHmHuXINuvMtm9XI lp3btBaIsmXcF/ucW20uiftEVHbdavW6xd9YXgKbt3ADn5Bfzy2rKYFGmD1vwsO2KhpE 3v0sLb/ElZNQT9mLgNiGiRF/nhmS+dMyvia4y/N8MDxRVqe0ArzO+t8poOgpQyXGUJGz rsMvzq6Rc9bUurAphbyDsg4yoaljiItRd6AgO3xAyYtGfWh6S+D3cGcQWgOiJBi6AX3z iG/g== 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=oHtsxCSYUd2gQx6nOl/j5+YR8/zO/DUcFUjj4bAah3c=; b=egBbu+6wzpW5V1FMwH2oYqHV3voLifGm0EyJeXEjZgjrFWWaiemvU37tTlbGdB3cdT 1JLeKdxytvXJTe/3bEhtutZ/CK+RrO8COf+VgAHxXzdvjx0gYt7HX7hNKjiqhBaalcBb 5wIn+HI3epcWjtvQgYnjjRAQqJjmw7JBy/XlIWT+rDMEkT7TUqRTgc3e1R2uQUXzJg0I KklqHZ5PsqTsBy+WFJoCT7gzK/MPcDFeJAuLUNOdUEFDNYdJoNkaYTWwvzPeb0M2M5iu vLo0pMs2ZM7Qflxc89/QcgW+GmJZIlggKk5ypwYyIOufbFateCeJOHLvysu6nwzetu8K l93Q== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id s16si1165061lfp.6.2021.10.13.09.01.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Oct 2021 09:01:33 -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; 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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 19DG1VuF025858 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Oct 2021 18:01:31 +0200 Received: from [167.87.2.42] ([167.87.2.42]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 19DG1VaP001191; Wed, 13 Oct 2021 18:01:31 +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: <9e00edbe-efd1-f1a5-de4a-9577007422ed@siemens.com> Date: Wed, 13 Oct 2021 18:01:31 +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: 7ed9TTNW1ZOb On 13.10.21 17:18, Schmidt, Adriaan (T RDA IOT SES-DE) 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. > > Exactly. In that way also patch 05/10 in this series is similar. Here the added dependencies on isar-apt ensure that things work also when stuff is taken from cache instead of built. > >>> 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. > > An `ack recrdeptask poky/meta` shows > > classes/package_ipk.bbclass > 282:do_build[recrdeptask] += "do_package_write_ipk" > > classes/base.bbclass > 349:do_build[recrdeptask] += "do_deploy" > > classes/meta.bbclass > 4:do_build[recrdeptask] = "do_build" > > classes/image.bbclass > 108:do_rootfs[recrdeptask] += "do_packagedata" > > Plus some more in specialized images or other package types. My feeling is that recrdeptask was created for this exact case we're facing here. > Sounds like more fun ahead ;) Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux