From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6467463440282681344 X-Received: by 10.28.156.86 with SMTP id f83mr132640wme.5.1506077802157; Fri, 22 Sep 2017 03:56:42 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.74.66 with SMTP id x63ls78655wma.10.gmail; Fri, 22 Sep 2017 03:56:41 -0700 (PDT) X-Google-Smtp-Source: AOwi7QD5RCKLBp625IXrA7H7BvpVrs7pXy+QXExFMxGLgHPsYvuGXXr+hM2ynk/cHNwTbYtEJ77H X-Received: by 10.28.9.12 with SMTP id 12mr124856wmj.7.1506077801762; Fri, 22 Sep 2017 03:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506077801; cv=none; d=google.com; s=arc-20160816; b=N6U+Apm/fvyT8xsX34QJEo4LWOZdyAwcpVYPKfo0UhuZRoz8OSxYFMJho31ViAMgIR sU+bL94JjVKuzEBKGnJHo3OLbL66BKNq6Oc/4YSBDLQkLLuj6o04WxIV9771FPHigjgH A8nu7MvwOvWMuJpMhJEByOePfSTN5Bmw5d7ig+dCy9JvDD+71AsygBEWEN84Nm6IWlb/ ky8gflC41qnD1XuDbQTIFLVQVyhdvlu9bMJ5WD8l6YpzUbXH6i1cxIeTf0qS4lMndRNv u4t0Aec8yX7toGu2WnneeA1eJeg+xYR8zH2nq3BltcZxKLZdnGImIW6G/J4Ip+Don5za lW0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=ARVkLg5BvuS1DJxtHB+ukglTo23NFvEduSF/yx62vwI=; b=ZIOrLNVpD5Mc4sKXB+0/9wrqJ8/JQ2ZO78rupP5GXCbaGNf/QPSmyQZ2g7OWx6V8Q4 aUx4Lg5yacjK/0OM2rqwuX8BB9ddSqqkCcsSBdu/7D3+HkrsLGtfqN0xWYWlhPwTHh6T cl0cdKOu+plhlP+y5jd0yuyNOLn3+I1l6yXYLYFdrZSCFHinvtd1ljm8WcJo3iFU02SJ +dRVWbznOEjxn20BeEg2LcGvbgMxtz8+0E9qXX1mmk7XWUZ7n2nsUxz05Zmrsc6UBeKd 1rj6HYFmBKYmmWPWAF+3IviWXAyfiplAd25xYzK71wK0iaBRiyys3UoSU3W2GWkWFnxU 3IZg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id 200si91418wmj.0.2017.09.22.03.56.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 03:56:41 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (p2E51BE6D.dip0.t-ipconnect.de [46.81.190.109]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v8MAud2w022452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 22 Sep 2017 12:56:40 +0200 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id v8MAud7E009021 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 22 Sep 2017 12:56:39 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id v8MAudC0009020 for isar-users@googlegroups.com; Fri, 22 Sep 2017 12:56:39 +0200 Date: Fri, 22 Sep 2017 12:56:39 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH v2 2/4] meta-isar-bin: Generate cache repos Message-ID: <20170922105638.GB4240@yssyq.radix50.net> Mail-Followup-To: isar-users@googlegroups.com References: <20170919122052.28688-1-asmirnov@ilbers.de> <20170919122052.28688-3-asmirnov@ilbers.de> <20170920101159.5b086d0c@md1em3qc> <69b055e2-e711-8a94-3e1b-0f066566d7d1@ilbers.de> <20170921085535.GA27874@iiotirae> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170921085535.GA27874@iiotirae> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: sfNPzDnTXVFw Hello Andreas and Claudius, On Thu, Sep 21, 2017 at 10:55:37AM +0200, Andreas Reichel wrote: > This looks like a misdesign, because meta-layers should not be populated > by the build process and furthermore, should contain recipes and not a > cache itself. It would be like the sstate-cache lying inside meta-oe... > > Why not define a variable like 'DEB_CACHE_DIR' or something alike and > use this directory. Then you also have more flexibility and can handle > multiple different caches, i.e. the caches become selectable and > independent of the layer itself... > > Furthermore, you could set the DEB_CACHE_DIR variable in the local.conf > snippents for multiconf and then you can have separate caches for > different target architectures and don't mix everything up in one pool. > > This way you can easily drop a pool by architecture without sorting > files out. I share your concerns and don't like that myself. That said, it's a demo implementation we ended up considering the following project requirements: R1. Product's binary repo is persistent across builds on the same host and across the hosts of different developers. R2. Building isar-image-base should be kept simple. New users should not be overwhelmed with repo setup, external tools, or manual configuration (as much as possible). R3. Build directory must be removable at any time without affecting cloned or newly built binary cache. We've translated that to the following design points: D1. Apt repo is versioned, e.g. in git. D2. Config files for this feature are put under isar/... D3. Given D1 and D2, binary packages go under isar/... :( . The idea is that in a project, the cache is a separate repo at the same level as Isar: product (originally cloned from isar) product-bin So, for production use, a tool like kas should be used to clone both at right revisions. We didn't want to do that for the demo due to R2. Just like meta-isar is currently a template for real products, meta-isar-bin is an example that should be moved out of the product source repo for a real product. Technically, meta-isar-bin is a layer that contains configuration files that have to be put somewhere. As package installation via apt is a requirement (dpkg doesn't install package dependencies), meta-isar-bin should become the default and would thus be required in the current implementation. We had considered cloning meta-isar-bin into the build directory, but that would mean manual configuration for new users, and (possibly modified) configs could be deleted if the build directory is deleted -- an unpleasant surprise for users familiar with OE. If it's a separate directory, the config files should go there, since they are per-repo, and there could be several ones: product company-bin department-bin product-bin For a source distribution, having binary repos as layers sounds perverse. But given Isar's focus on binary packages, it's layering in the sense that more specific repos could override more general ones. In the future, we'd like to move more stuff into the core Isar (either moving files from meta-isar to meta, or merging meta into meta-isar and introducing meta-template). Maybe we could introduce kas in a simple way, which would solve this problem. So, ATM I'd suggest to document the steps regarding meta-isar-bin for creating real products. If anyone has an elegant solution for the issues above, I would be glad to hear it. I agree with a separate directory approach, but suggest to postpone it till we find a good way to introduce it to new users. With kind regards, Baurzhan.