Re: [RFC][PATCH 0/6] Isar build reproducibility

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2018-01-03 15:03, Henning Schild wrote:
> Am Wed, 3 Jan 2018 14:54:10 +0100
> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
>> On 2018-01-03 14:49, [ext] Henning Schild wrote:
>>> Am Tue, 2 Jan 2018 17:57:38 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>   
>>>> Hello all,
>>>>
>>>> this series proposes the way how build reproducibility could be
>>>> implemented in Isar. General idea is to get the list of all the
>>>> necessary packages for build, fetch them and create local repo,
>>>> that will be used for further builds/
>>>>
>>>> Briefly speeking, it works like the following:
>>>>
>>>> 1. User sets the list of images that should be 'reproducible' in
>>>>    BASE_APT_IMAGES variable in local.conf file.  
>>>
>>> I am with Jan here, i would prefer an all or nothing approach.
>>>   
>>>> 2. Based on the list of images above, Isar will derive all the
>>>> run-time and build dependencies for these images.
>>>>
>>>> 3. Using multistrap, Isar will fetch the list of packages and
>>>> create base-apt local repository.
>>>>
>>>> 4. Now buildchroot and image root filesystems are generated using
>>>> base-apt.  
>>>
>>> Patch5 makes base-apt and Isar the only repos for a
>>> rootfs/buildchroot. How do images, not using BASE_APT, get packages
>>> that are not cached? 
>>
>> Another reason to split the caching and local redistribution repo that
>> will be filled by local builds from this mirroring and pinning repo.
>> For archiving purposes, there than later be some tool/task to export
>> both into a single repo, but we need a separation during builds.
> 
> Not sure what you are talking about, but there will be two repos.
> "base-apt" which will contain all .debs from repos we fed into the
> first multistrap - presumably official Debian mirrors. But all of the
> partitial mirrors merged into one repo. And the second one "Isar" which
> will contain what came out of dpdk.bbclass or dpdk-raw.bblass recipes.

Ah, good, it's already split. But then, while base-apt might be opt-in
only, the isar repo cannot be optional, i.e. dependent on that BASE_APT
control (or however it may be called in the end).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux