From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6467463440282681344 X-Received: by 10.159.63.193 with SMTP id m1mr3088292uaj.123.1507127360253; Wed, 04 Oct 2017 07:29:20 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.159.59.232 with SMTP id y40ls2821713uah.3.gmail; Wed, 04 Oct 2017 07:29:20 -0700 (PDT) X-Google-Smtp-Source: AOwi7QD3jxk43k4bf1QO6KsSWmw9ywkqWxKqZXgB/5L/lCeHq6DPyeyvKvp4WrAQq3GTb8S+vtUY X-Received: by 10.31.230.195 with SMTP id d186mr4348869vkh.111.1507127359988; Wed, 04 Oct 2017 07:29:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507127359; cv=none; d=google.com; s=arc-20160816; b=bEEaQ3OCb9N5MEmzlKtZ//7MTUSCkRFOqGT2+1FDGPajB12pqL2I7gWA5TV8J7vzZu A39SekzQsOO1Bhx6UEyxjAzOzSLrdWiH9OU0zOfvdLxURwn03bdbHezq/a6zHm9lmi6j zPyGTk2CV1enxkLd1iPzy738SiKJr32KpMj3ENFZlNg4P9gcBzVweM91C7Vecw7Lyp40 jcwudOBeYMxRJhXxfWGCLyCIBKFCeHX2iebZL0BWvWfXBiQNNwEHi2f/KamusLgqvnNf ePNqB5+e9K/jD+dok5neQ+oS7khxMPDSacgwTuRW60FbRgFHneZONE57ZbJaeSaEZeXX WLbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=vznyZVCKKBi5k+xM990I4iecPJKomRG82dY7hzgS5Ac=; b=ye/a/ljLWFTAhcAB10cz5NPEjVElS8KexvA06d6vw2vsg4WrqPd9qbNOKD7w+ykqy4 ZsNxTh0ROiQPpVe61+1NqL/kbb62s/3Ic0fpSACQL0r4Aup6Yp9IndoOgRhERmS0V/Ky 70dLytDEMiEZA+2Rx5I+bLkjE6CDTq5Zmxc6lg4Tdgul/Xrh69LyoABO9a9h/GPhHqEI Bzj6qQjfPv3uptEiqVfKClFgA/CLxw2P7HElzsqyAQ8591BAUS3EwbsNqkqnQDHBtgzv lt7dH8d+4JPMZnhVfJPcGSfmFRGsYzQ7Msxhw1AAfQy21zP8GFllfCd4C8gdGiE4vY/X 5aVA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id r203si738304vke.11.2017.10.04.07.29.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 07:29:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v94ETDCO032374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Oct 2017 16:29:14 +0200 Subject: Re: [PATCH v4 0/4] Basic binary cache implementation To: Jan Kiszka , "[ext] Claudius Heine" , isar-users@googlegroups.com References: <20171002154531.4930-1-asmirnov@ilbers.de> From: Alexander Smirnov Message-ID: <2e00bbc9-9823-850e-9451-9d66350713b5@ilbers.de> Date: Wed, 4 Oct 2017 17:29:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Dbj9Tv31Dbxi On 10/04/2017 02:57 PM, Jan Kiszka wrote: > On 2017-10-04 10:32, [ext] Claudius Heine wrote: >> Hi, >> >> On 10/0 '2/2017 05:45 PM, Alexander Smirnov wrote: >>> Hello everybody, >>> >>> this series introduces basic binary caching for Isar. >>> >>> There is a new layer: meta-isar-bin which is intended to be the binary >>> cache. All the packages that are built in Isar are stored in this >>> cache using reprepro. >>> >>> Having the separate layer makes possible to manage this cache separately >>> from the Isar build tree. So once you have built your packages, you could >>> re-use this cache for further builds. >> >> We still have to talk about your requirement for the cache to be >> sharable and your resulting implementation of it as a meta layer. >> >> Since I still don't see the benefit of a sharable cache and think that >> putting binary packages into some kind of strange meta layer is not the >> right solution and could potentially create more problems that is solves >> because its very much in conflict with the fundamental idea of a meta >> layer. The last statement is a bit strange for me. The idea of meta layers is to split software stack into logical layers that could be enabled/disabled on demand. Having binaries or recipes doesn't matter here, it's just the way how software is provided to build. > > Indeed, state like this (disclaimer: i didn't look into all details), it > sounds like a weird architecture to me as well. Thinking of an artifact > cache, I would rather expect something like OE's sstate that one may > preserve across builds, share between devs, or whatever. If it's there, > the build system consults it, if not, it rebuilds. But sstate is not a > layer, for some good reasons. > Let me again summarize major points here. Isar is the build system designed to work with binary packages. That's the key feature of this product and main difference from OE-like systems. The Isar architecture assumes to be designed around binary packages, what provides absolutely different approach how binary images could be generated using bitbake. According to the Claudius's vision, that everything should always be built from sources - Isar is not the best option here, Yocto and OE are much better, because they were initially designed for this work. Attempts to apply OE design and philosophy to Isar could have negative impact and limit possible ways to implement custom features, because OE wasn't designed for this features. Also I wonder why we are able to use binary Debian packages, while the rest of software should be built from sources. This series introduces support for binary apt repositories in Isar. This feature is response to the following cases: 1. Publish custom apt layer in web. When I need to install some custom software to my Debian system, I frequently see instructions like: - Add 'blablabla' to your /etc/apt/source.list - Run apt-get update - Run apt-get install That's for example how Jenkins and GitLab are distributed: https://pkg.jenkins.io/debian/ The management of this public apt could require some manual effort, while Isar (in plans) could update it automatically, so you update source code for your product, run Isar and it provides complete apt that you could upload to your server. 2. Implement easy software update. On our host systems we usually do not flash whole image if we need to update some packages. The update is performed using 'apt-get install' (or by similar tool). But in this case binary repo is needed, what could be again provided by Isar. Please do not limit Isar by deep embedded application, host systems also could be managed by Isar. 3. In long term, help Debian community to manage Debian infrastructure, what includes publishing apt updates. -- With best regards, Alexander Smirnov ilbers GmbH Baierbrunner Str. 28c D-81379 Munich +49 (89) 122 67 24-0 http://ilbers.de/ Commercial register Munich, HRB 214197 General manager: Baurzhan Ismagulov