From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478205302134013952 X-Received: by 10.25.26.147 with SMTP id a141mr484855lfa.30.1508335728457; Wed, 18 Oct 2017 07:08:48 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.29.70 with SMTP id d67ls93464ljd.4.gmail; Wed, 18 Oct 2017 07:08:48 -0700 (PDT) X-Google-Smtp-Source: ABhQp+Sjv+5Fiu6BltTW+CafVlWZY7fOAcg6GXOGI7StLmjYGkXcX5c0Y6PcDycEtCLqRDoD0rA8 X-Received: by 10.46.66.133 with SMTP id h5mr204173ljf.43.1508335728224; Wed, 18 Oct 2017 07:08:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508335728; cv=none; d=google.com; s=arc-20160816; b=lm0W/11bQ0UBCNAnoVGwZvLxPP8Z3zVHeBnQPzJE6WtO+ylYzFYAu/2SUeTHXcKv3a o20175Y6ksfw3RT0Nv3/vW06tazqU0vyojL+V8gb3STNA0SQG3HMdExACbtWxSUgMuJF NI9pUrx0g/SEJvh+JP0vcuTJQqiv9IrZYmtcUw672iX3kPihhEkLbtnAb9GIpnnJTke2 KrrVur28f7p/5WDa1SaaVzqnUBFkgs4/V8SRvovyPSNnuZpJLYhx4DtbkHuZ1W0tofYg BmwmMjjQg/D3E+l5m+uyy39D4B9uWB9ZkrsEyeanFtUTOA9RR8S/cgQ0NrsusYIl2rNm MVLQ== 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=8Ua1Bpz/qiGygZfMbMW/q4yML1yRumj8FVWne6MAsRo=; b=vOFvXJf0HBAewGhfGu7ICnZzjlGH2zMHoBEhscXXcqjLQQKpb9zUoCOeLD20qkjIB3 IVDrKjI668+g20vY0kHtlaJ/bE+Urykfl90+bXxAnH9v4YThGoX4cyMyXvFd0WE0FfoH Hsb2937wr5ak/MArTUpLupdfl2v8+pgtdNjVRecE6GpWP7xA8XmCOGLPlLHqjLCInLU3 dTLYeYQSoNrASI9GwM5WptQ2UNB9Kem4HadL9wwB0Mxj3N8ULXdwOPqPloWO+ZxRX0sz gucC5zDZhxrBLhoSss/vpr3mjy5H7F5IzwjIn2zNZowBoxAVvkOGG+UQPrbvvWYzkFBz Z8Qg== 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 l14si634803lje.1.2017.10.18.07.08.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 07:08:48 -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 mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v9IE8lk2011286 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Oct 2017 16:08:47 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v9IE8lXC017621; Wed, 18 Oct 2017 16:08:47 +0200 Date: Wed, 18 Oct 2017 16:08:46 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: Isar apt further steps Message-ID: <20171018160846.4e12413f@md1em3qc> In-Reply-To: <20171018160030.05b119f4@md1em3qc> References: <34795e4c-b50c-7799-d59d-9205a0413354@ilbers.de> <20171018160030.05b119f4@md1em3qc> 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: aufZXVmVu2sA On Wed, 18 Oct 2017 16:00:30 +0200 "[ext] Henning Schild" wrote: > 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. With the "URGENT" kernel changes we now have a situation where next needs to be rebased anyways, or do you plan to merge? Henning > > > - 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 >