Re: [PATCH 0/6] Local apt cache with aptly

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

On 2018-02-06 11:09, 'Benedikt Niedermayr' via isar-users wrote:
> Hi all,
> this series implements a PoC for running reproducible builds.
> The core is based on aptly, which is a nice mirroring tool for debian repositories.

In general, I would welcome a switch to aply and its exploitation for
local caching. But I have at least one concern below.

> 
> The mirroring solution does the following:
> - Aptly generates a mirrors for upstream repositories as well as snapshots and also a local repository for isar packages.
> - Get a list of all packages for mirroring before rootfs and buildchroot is beeing created.
>   This is done by running an own bitbake cooker for parsing the recipes by taking append files,
>   configs, datastore and also selected layers(bblayers) into account.
>   This solves the problem when upstream repos getting updates between rootfs and buildchroot creation.

This will not address the case of generated debian/control files and
their Build-Depends, right? I'm not a fan of trying to extract the
information in such a collection run, simply because of such tricky
restrictions. Therefore, my proposal is to postpone any up-front
fetching to later, if at all.

> - Aptly will recieve the list of packages and calculates all further required dependencies for the mirror.
> - Rootfs and buildchroot will never pull from upstream repos but instead from the local mirrors.
> 
> 
> Open Questions:
> - Think about a more dynamic multistrap.conf generation. Ŕunning sed to multiconfig templates is not really flexible.
> - Get a better naming convention for aptly mirrors, snapshots and repos. This will help to get multiconfig compatible.
>   Where are pros and cons here?
> - Where to store the cache? TMPDIR might not be the best location.
> 
> This series is based on commit 384750d of next branch.
> Running with multiconfig was not tested, yet. But maybe you can do it?

Well, how does this series relate to the discussions Alex and I had and
the roadmap I proposed? And how do you see it compared to Cedric's proposal?

We now have at least 3 approaches, but we need to go down to one that
works for all. Constructive proposal welcome.

Jan

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