From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6600694396621946880 X-Received: by 2002:a19:cbd3:: with SMTP id b202-v6mr261987lfg.1.1536846871736; Thu, 13 Sep 2018 06:54:31 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:7605:: with SMTP id r5-v6ls632184ljc.13.gmail; Thu, 13 Sep 2018 06:54:31 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZwX9hN3WngdNxVcsCDJN2ZKYlfnbE92asg86hRC8atAAEr/XVs6dw9dxoztyNohftZdT6c X-Received: by 2002:a2e:87cd:: with SMTP id v13-v6mr194854ljj.10.1536846871179; Thu, 13 Sep 2018 06:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536846871; cv=none; d=google.com; s=arc-20160816; b=wzBVnSrbnRFwJStBlVuQ2XvqiUmxRmNQWZpcW/EEV015zwDtOHURLyTSsCMCBOSFmY LJLrUAkuDdyzyURsS5KZt0Vn0xgqalWHjymtG77ZautjWzUry3AG86/74Piifvcc38KZ Nlkh9oGcImrDmu02eY3qwxyiWtXBOlZiZoKItdeQJtp7zLc6MDfG21zrAhbAsRnBA3yU YnlTuLyamIQMz29Tw7zAFcTd9iFOfJ5M1Ek0oU/QHTMNTxpw1UjkEk3B3WkT4V8JIarj 5mMPKA4HGypPMf652ctgzNW/oSSsXtJbO/G5eEs3DuJmN1LUNK4yAtTJHDVVpy/YSHsB M3bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=+ljrVSv28l+B2Yafy7idpLndoIvGiUNbp06S8+7p2B8=; b=kDPoH3QyN/P523JTQtLIu25l5HMWqD66PwFsUxnuirqxPIb6/JQBrffK9i/U2fhwbF 1aZ4PVgWeEXu6ws+/q8H+LwGlzYAYP55OKp4kebpaRDAiSl1bpVZXZUFcktsQvP/i+Ke U2OKG4ix5Egq6XXgF0b66nFZoU9yXqENSraNssAZFLbT77qHft7Se9keCygrYWMsDfDQ vov2s3ZAwA6mLtF8jh2BUBvm/YQ7z8xpgknfR70g1z9tI6CbIPG1xNTomlIBn8t2qZwj NmJuWTFmMQg9zxs20T5cqsPhILnehgzpqIG1LW0UlJlMOCVYDDLCHH30j2bqOlMRs6SR 4vzw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id m2-v6si159195lfi.4.2018.09.13.06.54.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 06:54:31 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w8DDsU8d009616 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Sep 2018 15:54:30 +0200 Received: from md1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w8DDsTwZ013494; Thu, 13 Sep 2018 15:54:29 +0200 Date: Thu, 13 Sep 2018 15:54:29 +0200 From: Henning Schild To: "[ext] Jan Kiszka" Cc: "Hombourger, Cedric" , "isar-users@googlegroups.com" Subject: Re: RFC: need to support package builds ala pbuilder? Message-ID: <20180913155429.52daa5b6@md1pvb1c.ad001.siemens.net> In-Reply-To: References: <5469172f38754fd6b432249a3bd1bd8d@svr-ies-mbx-02.mgc.mentorg.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: FcHK7dnmODwc Am Thu, 13 Sep 2018 15:15:00 +0200 schrieb "[ext] Jan Kiszka" : > On 13.09.18 15:05, Hombourger, Cedric wrote: > > Hello all, > > > > I recently came across an interesting case that may require us > > providing a mechanism to support building packages in their own > > private buildchroot Let me first describe the issue: > > > > # Isar defines two tasks to build Debian packages: (1) do_prepare > > and (2) do_build # The former installs build dependencies while the > > latter does the actual build # > > # The Isar lock is acquired for do_prepare_build to serialize > > access to the package # database. While this looks ok, we may have > > builds fail in the following scenario # > > # core 1 core 2 > > # -------------------------------- --------------------------- > > # > > # recipe1:do_prepare_build > > # | download dependencies > > # | install libssl-dev > > # | task completes > > # recipe2:do_prepare_build > > # recipe2:do_build | download dependencies > > # | autoconf | remove libssl-dev > > # | make | install libssl1.0-dev > > # > > # Running "autoconf" or "make" while libssl-dev gets removed to > > allow installation of # libssl1.0-dev may cause either to fail > > since OpenSSL headers / libraries will be # temporarily removed > > If recipe2 (or did you rather meant recipe3?) depends on libssl-dev, > and that is built without a proper dependency encoded, that's a > recipe bug. that build step must not start prio to the deploy_deb > step of the producing recipe is done. No they just build two packages against different openssl versions, where the -dev packages can not be installed at the same time. I guess that is a special case and i would serialize such builds with DEPENDS statements, maybe in .bbappend files. > > To keep locking simple and avoid introducing a big fat lock for the > > entire package build (do_prepare_build + do_build), adding an > > option for a recipe to instruct bitbake to create a buildchroot for > > a specific package (e.g. > > tmp/work/my-distro-amd64/my-package/buildchroot) may be necessary. > > This would result in something conceptually similar to pbuilder but > > integrated into Isar. The downside for those packages is that we > > would likely end-up downloading the same packages again (not a big > > deal for those of you using a local caching proxy such as > > apt-cacher-ng) > > > > I therefore wanted to seek your opinion in either the need for such > > a mechanism or alternate solutions you may have in mind? > > The above thing aside, having "clean-room" package built rather than > sharing the buildchroot would be a valuable feature, to catch recipe > bugs early and more reliably. Agreed. We can even reuse the debootstrap output, which might reduce the "time"-cost to acceptable. Either keep a copy or go for union mounting with aufs/overlayfs. Henning > Jan >