Re: [PATCH v2 2/4] meta-isar-bin: Generate cache repos

[Claudius Heine <claudius.heine.ext@siemens.com>]

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