From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6467463440282681344 X-Received: by 10.28.138.195 with SMTP id m186mr2682522wmd.9.1507118248443; Wed, 04 Oct 2017 04:57:28 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.195.40 with SMTP id n37ls3677976wrf.2.gmail; Wed, 04 Oct 2017 04:57:28 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDdycpgOaiiyaDyiBLQUXCcE79YfuVPsf6iuM5VPTLB3gvYyI4pHmPlfQSiRT3mhLyF2hlq X-Received: by 10.223.157.134 with SMTP id p6mr2149258wre.14.1507118248182; Wed, 04 Oct 2017 04:57:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507118248; cv=none; d=google.com; s=arc-20160816; b=ZP6Ko3XMO8W78HRVc5pFf1dbRWMnexwUY3804jDeU1Q5CxSPl8d5IliyJv/ZOir6qZ a/A/vJa3hMg+0MriYimiXbaJ+1xm58PFc/krCQkMG/jlcsPC/va8N3ZCW9/i24B6/glE FamaGttFshSUjgyW60M+AbRAbuitr9HPq11aFSL8mbSkcjF7ddCSgAZKNCSbQD9b62fn 2UAPGxP4fF2CBS87SzJ2gmCeyJIriTinonfFp2hkD4DRnXFr2vQoA2m1AarD/l5LnnhK Jp8e9lDByT2YQEkV2KUbkKhnaogwVaYkPLqINPlcl3ENBZOPJdyoHSVb6yhG+5zh+gPP LZBA== 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=LusCeujwhsUwKQmn8+yxcJ0CvLSAkqS807e3fsQaPRg=; b=vQc62mLOUH1kQrzrUiGXUksION3Ha0LIx9UmbmgBsGw8LhspxefqZdWjtK4F1eoLN5 zP49m8r+JphwayhtiZDPpten3rJ1/94iit9GPYGn0S/fBaFy0aY8YReAgX/HUAc5gnZ7 9owb7H4jAGx8eFK32R7xSyt9qETKLIjlBWf1SDclpy9FeNlrk48cHImI2C6X4wiDAlmb ItN/eV5PSwJI4pKa+SKXf6m5A5LK0QByzJd6cYikYbxWRZ6tXmePVkgspiEU1mrMQnKa MZO7Cn0vfNeYls9EqYR1wvU6wZ3t998ZObfsp9LZneqi003jZ1IZQ3N3u2HJftVSJEUC PLRg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id r65si1617592wmf.2.2017.10.04.04.57.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 04:57:28 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@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 v94BvRCl020167 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 Oct 2017 13:57:27 +0200 Received: from md1f2u6c.ww002.siemens.net ([139.22.57.11]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v94BvMMb023550; Wed, 4 Oct 2017 13:57:25 +0200 Subject: Re: [PATCH v4 0/4] Basic binary cache implementation To: "[ext] Claudius Heine" , Alexander Smirnov , isar-users@googlegroups.com References: <20171002154531.4930-1-asmirnov@ilbers.de> From: Jan Kiszka Message-ID: Date: Wed, 4 Oct 2017 13:57:19 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: PM39D/J5f6o/ 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. 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. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux