From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7156173593333727232 X-Received: by 2002:a6b:4114:0:b0:6d2:76f4:e041 with SMTP id n20-20020a6b4114000000b006d276f4e041mr36909771ioa.11.1670922820786; Tue, 13 Dec 2022 01:13:40 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5e:9813:0:b0:6de:9e24:a442 with SMTP id s19-20020a5e9813000000b006de9e24a442ls2403396ioj.9.-pod-prod-gmail; Tue, 13 Dec 2022 01:13:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf60jzM2CjIzzxhQByW54Yx7TpkKWf/TaDldlYn4jfDXMTJaMI1jJpqUjz9CumFXNJTMWkln X-Received: by 2002:a6b:4e0e:0:b0:6de:383e:4138 with SMTP id c14-20020a6b4e0e000000b006de383e4138mr11997554iob.7.1670922820233; Tue, 13 Dec 2022 01:13:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670922820; cv=none; d=google.com; s=arc-20160816; b=C0hL8GRwi8eAlGmoZmAwKGZslKvaniZgb0hQGNSrD/Jtx764+QAL54lev/W8HJpTeH A/Hky8InKwRK9oAhoE4eCsBlczDCCteY8ONh8IIr6kMOq9iEMHKdZU/jVZKUl1GK9Xf2 uYwi/A9k/jP2rRs+usH5+BsZFEWaP0iWen1jBsxRlzHpu0uMdEhBP5AYopGRz1RW+Jem A2U3XwCat9kszpXOsTS0EyHhwSuHnpsH5YARClThqe2AXLR4DcbF8BXNdu465i6uA1LE okdGQ8PRsqjouDhZgQlPKvUShTNeX2E9SCUt+q/nCJm9Xyw6peTDbRgJJNfIjJshe4Gw W74g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=48a81o2FQWLHy/I9NXLA1gjSd+uQb8ylBQv7KhagK/0=; b=UnpVWllMANdw+fLsIbeZ9GO8WY8gAgpAkjwZcc+OdLzO2a4WFUJrHo2NQ9fsPKVLg+ XpfpTrNLnyPPEP5UHLPqn7YWI4NaaSWoAkIZ3KMkShXL2jUZ6+Pdj4m2oGZL8tpcu4ar mDSTHu6+TWMpJ5lV0vY+hxPneDKxACApsFtV7ipfZEfxwoyQ3FkYZ02KDxO9cZhPsMZn xHhB38J5PembPTfINtNLoxAe6FyCSNCi/ZUmerjixaVfslITGfq2C2Dau/PeU7iXjnbK dAVXDMG6J8XuVDC5n0MbBw2eBcGv8LX0UxhwQ0y09Cwg9Laya+L1xOnmYoUSHnTQPxc+ sn2g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id h13-20020a0566380f8d00b0038a31b473acsi126059jal.4.2022.12.13.01.13.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Dec 2022 01:13:40 -0800 (PST) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 2BD9Da61032678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Dec 2022 10:13:38 +0100 Date: Tue, 13 Dec 2022 10:13:36 +0100 From: Baurzhan Ismagulov To: "isar-users@googlegroups.com" Subject: Re: [RFC PATCH] Remove isar-apt and the corresponding lock Message-ID: Mail-Followup-To: "isar-users@googlegroups.com" References: <20221019104745.479166-1-adriaan.schmidt@siemens.com> <218a82b49fc504cefab83e79a995fbd6d9da554c.camel@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <218a82b49fc504cefab83e79a995fbd6d9da554c.camel@siemens.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: LGWCAkzQurLT On Tue, Dec 13, 2022 at 03:44:09AM +0000, Moessbauer, Felix wrote: > The point is not about removing isar-apt all together, but removing the > global state which is shared across the tasks. Having this global state > is bad regarding the following aspects: > > - reproducibility: We inject data that is not covered in any bitbake > hash > - blocking the scheduler: The access lock reduces the parallelism and > also smudge the statistics > - no way to remove packages between two invocations of bitbake: > This is mainly relevant with local re-builds and pre-built packages > where only some should be deployed to the isar-apt. I recently debugged > such a case for an hour to understand why not the upstream package of > ntpsec is used, but my broken custom-built one (which I removed but > still lingered in the isar-apt) Thanks for the specific aspects, we will look at that. To my knowledge, at least the scheduler topic should not be an issue after sbuild migration. Reproducibility and removal are technical issues that can be improved, there is nothing inherently broken with the approach. In general, we rely on Debian tooling for building packages and root filesystems. Those, in turn, rely on apt. So, for Debian, apt repos are the transfer mechanism. There are some aspects where Debian, being a distro and not a development framework, shows its limitations for our use cases (version number bumping, etc.). What I'd like to avoid is to create an inherently source-based distribution disparate from Debian that emulates some deliverables at the end; we should evaluate our use cases and look at enhancing Debian workflows if necessary. > PS: I cannot access the mentioned links, looks like your patchwork is > down (or something is broken with our network). Seems to be ok at least according to https://downforeveryoneorjustme.com/patchwork.isar-build.org With kind regards, Baurzhan