From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6600694396621946880 X-Received: by 2002:a1c:f60a:: with SMTP id w10-v6mr756070wmc.19.1536843924733; Thu, 13 Sep 2018 06:05:24 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:5588:: with SMTP id j130-v6ls1432619wmb.6.gmail; Thu, 13 Sep 2018 06:05:24 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZvkPlOLbw4abZ7OESE8EodusvuMPGk6mYxetXtwiLrD7GN4qjMvpJr4qhYTyZTY9TY3RWR X-Received: by 2002:a1c:7319:: with SMTP id d25-v6mr715280wmb.10.1536843924298; Thu, 13 Sep 2018 06:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536843924; cv=none; d=google.com; s=arc-20160816; b=yS7qPysNLobCwR3QsxdkuNzi8OkoppUtlh1wMDkEl52aUXnLhriI4zgWRIue3TWft0 j7mXZFumWsLxlYXbkcxUeompz/znALCnXVO50Q74N8Jewxdp7SeF+NAED+FYfF7FOY6c 0bNhiwFJPev7K+InNJIVprQqZkztAn5+4608PLG9lB+p6zLegbM2n+2bOY560walgV7K pkzP144/3z0CSRDS+FIHi6/zrqXy93SuhKnM5b1qa1CglC6TAr2DhrYdOPc9k71BGF1j Mnjdu8xOXfgGP+ih+D1pclv9LgW+hOaYbRKfQNmq7TpmEeWYcPfSRCrN0RpjvLbBSMMw 5l6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:content-language :accept-language:message-id:date:thread-index:thread-topic:subject :to:from; bh=TaRcuEVgt6g7poRFp9gjGCBgtIadocrWxRSorpSj64c=; b=dManVqBFUsHne8Fr1m4NKX04hYG0txgAcwqyoa8yc7eUSMgzXL7b1w/3kii22gjrHD +QQAS1prj3pshLA07EfXzdnCor/00xGOojtzbJb3XUgsZ1dfCIKXMZJr44Tk8RdLWgd9 Sibm+t3k4iUGqwuzaxjgeiUgTcklaGSHA/bQKmWvrNUlB86dsPI+9MPj4u6z61ACuXp5 7assyrNv6An8cKY9G7XLNYuca6Int15xmPBVIDcXTj/mGiZADA7RTRu87Z43TaIQ7fU4 y3uemXRVgdzn0ytFKTEtkb08S81wJJA4C0x3QEE17QdsmfnbEjTfqGvtNv5NdHziwGRq 0hEg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Return-Path: Received: from relay1.mentorg.com (relay1.mentorg.com. [192.94.38.131]) by gmr-mx.google.com with ESMTPS id l15-v6si133420wre.2.2018.09.13.06.05.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 06:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) client-ip=192.94.38.131; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-02.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1g0RJC-0002CW-V2 from Cedric_Hombourger@mentor.com for isar-users@googlegroups.com; Thu, 13 Sep 2018 06:05:22 -0700 Received: from svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) by svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 13 Sep 2018 14:05:19 +0100 Received: from svr-ies-mbx-02.mgc.mentorg.com ([fe80::a01f:51c9:5b6c:e0c]) by svr-ies-mbx-02.mgc.mentorg.com ([fe80::a01f:51c9:5b6c:e0c%22]) with mapi id 15.00.1320.000; Thu, 13 Sep 2018 14:05:19 +0100 From: "Hombourger, Cedric" To: "isar-users@googlegroups.com" Subject: RFC: need to support package builds ala pbuilder? Thread-Topic: RFC: need to support package builds ala pbuilder? Thread-Index: AdRLYWVhkUVS5utPRG2QlS8TNAnyBQ== Date: Thu, 13 Sep 2018 13:05:19 +0000 Message-ID: <5469172f38754fd6b432249a3bd1bd8d@svr-ies-mbx-02.mgc.mentorg.com> Accept-Language: en-US, en-IE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.202.0.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TUID: V5ezoDH8sI9c 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) d= o_build # The former installs build dependencies while the latter does the actual b= uild # # 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 s= cenario # # 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 insta= llation of # libssl1.0-dev may cause either to fail since OpenSSL headers / libraries = will be # temporarily removed 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 bi= tbake to create a buildchroot for a specific package (e.g. tmp/work/my-distro-amd64/my-pack= age/buildchroot) may be necessary. This would result in something conceptually similar to pb= uilder but integrated into Isar. The downside for those packages is that we would like= ly 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 mecha= nism or alternate solutions you may have in mind? Thanks Cedric