From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478205302134013952 X-Received: by 10.80.222.130 with SMTP id c2mr4207449edl.8.1508335231820; Wed, 18 Oct 2017 07:00:31 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.241.28 with SMTP id w28ls1872486edl.6.gmail; Wed, 18 Oct 2017 07:00:31 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDYei+1bFxeoDNKv8x+ErKSICv2FV7i7dcHLRDE/di71zkLI/vHdxK9qaX38v53LyaSCjDq X-Received: by 10.80.204.74 with SMTP id n10mr4205374edi.2.1508335231539; Wed, 18 Oct 2017 07:00:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508335231; cv=none; d=google.com; s=arc-20160816; b=GQcSc5FM9kdMe8gkmfN2aV6gVtfclVp/f1Nk8q9/x4CM7XH/OcgCwXxIRKIcrnC+Fe 7Ccqx2jtJzo/ox4Jmd9/zLsqA2zzoRJvnFhVjVeXCjjVIKBujLS4o6s13UP1Y7ajMnQx cpbfYHC6Kc85OGsNqqZXtoRGJ5mZMs9Dv254l0SrRD+aElSTWaxIo5+pm0+0cCP/Mf2b TfGuE5ymXzV8IaU4sSX/agMm3jFQrsACAqkUjf9uWmD68Js4RNma19DXZXbmVzrEYEH9 v1q/fPYhpivpV7qg/TxSeNFMCkgoVv+0EBLpE5c9KBIYmPg51E37UwHlfM59CSOp9NYI urLw== 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:arc-authentication-results; bh=7Dhz72Kk8lDdG2lYNvmfW2r8K5UuWzvGKHRH2duzvBE=; b=BThkFQIiWJ+48zSDMWs1cxlBY4CnY2y05G2nSeXrnA5M/4XEpOOW05FKr/0/TQ21bo XlmCy8jPViYaVe2fQgQf8TyQkzVXBj8wXc5y6EuMLDRRE1iFfgZxXPIENp1lNJkeBiMW 6Aq01UrNfoq38VjxYK1Jh4dq4BnSnAriiGIQM8JcKYOXoxajpVzFHK0PHg+sbzuFsPIX rbF05AjUM6XdQjn8OgLFffJhP+wWwrT1Bm3j2Trx0a+6lMCqIJ/hKaAcB4bbFen3BMMp s7RJB/RTLeCfwBJ8dc5trodJRuNJKWHhYSNXYYKK5T8ywzjU5/F3MUBViUFB7GJPqAoX b1MA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id f9si714007edm.1.2017.10.18.07.00.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 07:00:31 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v9IE0VSn028849 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Oct 2017 16:00:31 +0200 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v9IE0U6U019628; Wed, 18 Oct 2017 16:00:31 +0200 Date: Wed, 18 Oct 2017 16:00:30 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: Isar apt further steps Message-ID: <20171018160030.05b119f4@md1em3qc> In-Reply-To: <34795e4c-b50c-7799-d59d-9205a0413354@ilbers.de> References: <34795e4c-b50c-7799-d59d-9205a0413354@ilbers.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: DdbswwDh/IsU On Wed, 18 Oct 2017 14:05:01 +0300 Alexander Smirnov wrote: > Hi Henning, > > I'd like to start separate discussion about further apt steps because > previous series was applied before your last comment: As i just wrote you in the original thread, please remove these patches, they are not ready to get merged and are on a rebasing branch. > > - create one task in dpkg-base.bbclass that does the following > > - config and init reprepro if no other recipe did that before > > Hmm, in general repository generation should be performed only once, > moreover in most cases it should be done for dedicated Isar image, > otherwise no need to cache binaries to apt if it's not used. So > that's why I've put repo creation to image class. If there is a way to express "image step to run before any package recipe starts". I guess all recipes "do_populate_apt" need a [depends] "image:do_cache_config" > > - add package > > If task[lockfile] works for multiconfig, then I definitely like this > approach. I certainly hope so. If not, you know my opinion on multiconfig ;). > > - use bitkages task[lockfiles] to deal with races between recipes, > > put distro into lockfile-name so we have one lock per distro > > - drop do_populate > > That's already in todo, the blocking issue was locking mechanism for > multiconfig. > > > - call the new task instead of, or in do_deploy_deb > > > > > So, to summarize my vision: > > 1. image.bbclass: do_cache_config(). Use [lockfiles] = ${DISTRO} to > handle multiconfig and 'bitbake image-A image-B' parallel builds. > > 2. dpkg-base.bbclass: do_populate_apt(). Use [lockfiles] = ${DISTRO} > to avoid races between recipes and for multiconfig. > > 3. Drop image.bbclass: do_populate() > > 4. Remove ${DEPLOY_DIR_DEB} from Isar. > > What do you think? Sounds good! Henning > Alex