From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6449326914083487744 X-Received: by 10.25.29.147 with SMTP id d141mr1681756lfd.20.1502439110305; Fri, 11 Aug 2017 01:11:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.22.11 with SMTP id 11ls201208wmw.2.gmail; Fri, 11 Aug 2017 01:11:50 -0700 (PDT) X-Received: by 10.28.17.69 with SMTP id 66mr1278969wmr.18.1502439110031; Fri, 11 Aug 2017 01:11:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502439109; cv=none; d=google.com; s=arc-20160816; b=iHSdl3GUgV6InC0pZsU1VH3+Y7FQHZnPkrHipHhrCV2a8Xuwex7ccVy5E8aruOO+nN uM6kGhfGBIYWMOj84RUx3XNS14LYLAeEZ1oNaaqEduwSdZUWit1YKgL3aH+oZ3rU8LVe /oDB0JZRqmzOCyRmA7S9tmvmPVsMYsFl/bpIY7VBKpm52TCGfUdYH7kMg4B3H6XiHJ2r xujKrP12NrkzTHk2w3cj1Hk47Al52s4PvO/ct2b7yR7BLcaaPhCu6D3P8KtcmfFlXmKi FT41m7ONkTbfcFbX6WJ33ytVULNk7GDlDmEpV+PzM7VRO3LqKEkN+G4jkOw4UuPWF4be S6sg== 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=f/AZMuH02HPflgf9uODavRnADtQ6n9oQ63ujoMp5J68=; b=cqRFeIz2Vf6ma3CyZHhHBLln/XMu6RePaTie32NdUF6h9cOGTQ0UFyTsuuWG9TopjA 1Nb4WjyMiOMz3oLAg5rfDMP+7xm6f72WLCcuFpIKtgv2/H5IF4iAFrQ3GS6MZI0nwxME ZUE3pYMKnAShOefugE9Gc+wx8jr85xBfB9s18aglEicIpXE1Ymho8RikaYSLV6SMQuDq WGlzBZPsUBlJK6louhFXFQpQGpzu8sD3E4OnxAuc7runBXk1fhr+qkQI975O65re7y60 ywJsuvWqZ4y+rvchOeY2/0Nvc7N3fQYbbPSyEnjI2r2lz3FLBfye/KItL+R/HV7OhqEC dkDA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id n202si5031wmd.3.2017.08.11.01.11.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 01:11:49 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v7B8BnRk023147 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Aug 2017 10:11:49 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v7B8BnCd000761; Fri, 11 Aug 2017 10:11:49 +0200 Date: Fri, 11 Aug 2017 10:13:46 +0200 From: Henning Schild To: Baurzhan Ismagulov Cc: Subject: Re: [PATCH 0/3] use local repo for multistrap and drop "dpkg -i" Message-ID: <20170811101346.3f5e67d5@md1em3qc> In-Reply-To: <20170810124627.GA3259@yssyq.radix50.net> References: <20170810124627.GA3259@yssyq.radix50.net> 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: /d+pOrBjGRW+ Am Thu, 10 Aug 2017 14:46:27 +0200 schrieb Baurzhan Ismagulov : > Hello Henning, > > On Tue, Aug 01, 2017 at 05:24:05PM +0200, Henning Schild wrote: > > This series introduces support for a local repository to be used > > instead of "dpkg -i" after bootstrap. > > Before we discuss it in detail: We have an implementation of apt > generation that is also used for binary package caching across > bitbake runs in the lenormf/develop-l20170602-dpkg-cross branch > provided to Hans and mentioned on the list. Which advantages does > your implementation bring? As i said before there are too many branches and forks around. I would like to keep the discussion on master and patches under review. A comparison makes sense after someone sketched the changes in a few sentences. > I like your dpkg-scanpackages approach compared to reprepro in the > existing implementation. Analyzing the rest and choosing / combining > the optimal strategy will take some time. I am not sure i like it because it is a plain directory. Reprepro probably has its advantages but is more complicated. > To speed up the process, > could you perhaps sketch the changes in the workflow in a few > sentences? The idea behind it is to introduce one policy. Everything that goes into the rootfs comes out of debian packages and their hooks. Multistrap is the only entrance to the rootfs. - solves dependency tracking compared to "dpdk -i" - limits fetching of debs to multistrap - if you fetch with "apt-get" in the chroot you get proxy problems again - you loose track of what you used for the rootfs - your rootfs needs apt-get installed - makes multistrap the valid candidate to tell us exactly what we used and allow us to create a partial mirror for reproducible builds - evaluate "retainsources" feature Changes in the workflow: - create a repo as the first image-task - this one has to wait for all .debs to be built and copied - drop do_populate which messes with the rootfs after our new gatekeeper multistrap > Regarding the kernel: Which arch and suite are you building for? We > don't install kernels in QEMU images because they are not necessary. That was just me building incorrectly, i did not know about the "multiconfig:" thing. > Regarding the increase of build time, I'd really like to avoid that. Me too, that is why i started the discussion on caching. Giving up on the gatekeeper idea would IMHO not be the way to go. > Building all configurations in one run already takes up to 40 min. CI is patient and for basic testing one does not need to build all of them. > The problem should be easily mitigatable by splitting rootfs > multistrap and apt-getting the built packages into separate recipes. Yes but that is what i mean with "giving up the gatekeeper". We could implement both ways controlled by a variable in a config. That would speed up the builds during development and allow switching to strict gatekeeper mode for releases. Henning > At least I'm not aware of any increase in the existing implementation.