From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6467463440282681344 X-Received: by 10.223.184.197 with SMTP id c5mr545103wrg.17.1505985706811; Thu, 21 Sep 2017 02:21:46 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.154.16 with SMTP id z16ls608247wrb.4.gmail; Thu, 21 Sep 2017 02:21:46 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBu05ipL2nlxRLt+wV9tNvdeTBwOjz0mVe1Ea0lS74FglcE4XTGRk32wxBh+jg21n7b+Q6m X-Received: by 10.28.1.146 with SMTP id 140mr41978wmb.2.1505985706667; Thu, 21 Sep 2017 02:21:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505985706; cv=none; d=google.com; s=arc-20160816; b=Ov5N1HouUfdhn2dloeHluvkWcKDNNYQE3pxayJlvsIQAsFZDoNTqFH5j6/uaD75XKn rc0KaMLyHHUcrHS4Ad18ufq+JrftNoPtBqZooGlMH6ID5vBDiUJcbyecH1POtuthg1bu 6HRp6M6WZVZ/R2D75Y00rbCULxqSn8SQRZx2vCJ0RI0BwI7CwmErxrhwhPCHG3f+5XwG pQYoc6oxQUjPBVqiBf2Jyd7Sa1p/0Rs11drKMyWFKeZeb/9QsvwSZS4coiuhMKh0oiQc isIXCtPuEzqTTmh7NFg9kFDempmuMeWem6HNH2EY9D8/27GkhLRjJIxMU1gjaFFsMf+4 oyTQ== 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:cc:to:subject :arc-authentication-results; bh=ydSPOXaralIm96uee+tWlH56UkWdyuGT00YmtUpjdnc=; b=nTuXqnWvDb3n7Avo0r+wNhz0atgq+DhgRK/6wnece7ndz4SwbJ2uLYNXkkxwf7tqW5 uL3LqzZdT5RWbiS+wh9kZFx7pFLUb9oOTgD4rInfAehvrzqBxCQnCgIMnz9khGIQB7MY /eruVh/czVgaYvDkMV/9BsKt779UvYZ+Fr/T9QugQP//fQb7q/JPAi4cHke3iCLmKs+N VkUhi2Rfruex01dpfLsRbv81mUxM2vhVHRbhwLHX+RdgU5whZmV9goNFtU1jart5TAyo W2jSUGuuhYikGLWgGgObHWgzX7U4eZKDAQRJnOxJpah9+SwVTiEJJaww6p0Y2rtaHVhh XJ6A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id c142si383050wmh.3.2017.09.21.02.21.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 02:21:46 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by domain of claudius.heine.ext@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 domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v8L9Lkkk030212 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Sep 2017 11:21:46 +0200 Received: from [139.25.68.223] (linux-ses-ext02.ppmd.siemens.net [139.25.68.223]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id v8L9LjxS024359; Thu, 21 Sep 2017 11:21:46 +0200 Subject: Re: [PATCH v2 2/4] meta-isar-bin: Generate cache repos To: "[ext] Andreas Reichel" , Alexander Smirnov Cc: Henning Schild , 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> From: Claudius Heine Message-ID: <7f0d134f-9008-cb4a-147c-3386aae3961d@siemens.com> Date: Thu, 21 Sep 2017 11:21:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170921085535.GA27874@iiotirae> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: BClM4V2+f4jv Hi, On 09/21/2017 10:55 AM, [ext] Andreas Reichel wrote: > On Wed, Sep 20, 2017 at 11:26:20AM +0300, Alexander Smirnov wrote: >> >> After build, there will be the following in the cache (example for hello): >> >> $ ls -1 meta-isar-bin/apt/debian-jessie/pool/main/h/hello/ >> hello_0.1+g7f35942-1_amd64.deb >> hello_0.1+g7f35942-1_armhf.deb >> hello_0.1+g7f35942-1_i386.deb >> > > 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. This patch is sort of doing that. It defines: DEBDISTRONAME = "isar" DEBCACHEDIR ?= "${LAYERDIR}/apt" DEBFILESDIR ?= "${LAYERDIR}/files" In the layer.conf of the 'meta-isar-bin'. So you could overwrite it in the local.conf. But I agree that this way of doing thing looks rather strange, because now we have a layer that does not contain meta data (recipes, patches, etc.) but instead it contains binary packages. The idea of layers is to have multiple of them laying over each other creating some kind of union file system. You can't do that here AFAIK. So it goes against pretty much the basic concept of bitbake and the layering. Also putting those build products in the meta source tree is very bold. I could imagine that those meta layers are mounted as read only into the virtual machine/container. This would pretty much break this. So I would be in favor of handling this kind of binary cache similar to how bitbake handles the the 'DL_DIR' and 'SSTATE_DIR'. Cheers, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de