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

["Hombourger, Cedric" <Cedric_Hombourger@mentor.com>]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

Correct, my (simplistic) approach was a two steps process: (1) build with upstream feeds to get what we need and populate a local repo (2) perform another build with the local repo to prove out that upstream are no longer needed

Something like Benedikt's is probably the way to go. As noted, the challenge is indeed to fetch everything including dependencies.

Will review and play with the PoC and try to think how to address the concerns Jan is having

Get Outlook for Android<https://aka.ms/ghei36>




On Tue, Feb 6, 2018 at 3:03 PM +0100, "Benedikt Niedermayr" <benbrenson89@googlemail.com<mailto:benbrenson89@googlemail.com>> wrote:


Am 06.02.2018 um 14:28 schrieb Jan Kiszka:
> On 2018-02-06 13:39, [ext] Jan Kiszka wrote:
>> On 2018-02-06 11:09, 'Benedikt Niedermayr' via isar-users wrote:
>>> 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.
> Hmm, does your patch address Build-Depends at all? Can you explain how
> they make it into the aptly mirror filter?
>
> Jan
>
> 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.

Yes you are right! That in fact is a problem which still persists, and I
will try solve it soon.

But I have also not tested 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?

Since I was developing an approach of aptly, for own education purposes
and PoC.

This patch series is only a PoC,  for running builds against a
prefetched mirror. AFAIK currently no approach

is based on using aptly. This series should give everyone the knowledge
that aptly is also working, and also demonstrate some extended features
compared

to reprepro.

Cedric proposal is not using a prefetching mechanism, or do I miss
something here?

And Alex shared his vision, by fetching all packages within a single
step/recipe.

At last I think, it is not wrong to have different approaches in order
to show the pros/cons more clear.

> Hmm, does your patch address Build-Depends at all? Can you explain how
> they make it into the aptly mirror filter?
As I just mentioned... Build-Depends where not adressed yet. I've
focused on a basic prefetching mechanism.

Today I will have a deeper look into Build-Depends, and give you reply.


Benni



[-- Attachment #2: Type: text/html, Size: 4666 bytes --]