Re: [RFC PATCH] Remove isar-apt and the corresponding lock

[Baurzhan Ismagulov <ibr@radix50.net>]

On Tue, Dec 13, 2022 at 03:44:09AM +0000, Moessbauer, Felix wrote:
> The point is not about removing isar-apt all together, but removing the
> global state which is shared across the tasks. Having this global state
> is bad regarding the following aspects:
> 
> - reproducibility: We inject data that is not covered in any bitbake
> hash
> - blocking the scheduler: The access lock reduces the parallelism and
> also smudge the statistics
> - no way to remove packages between two invocations of bitbake:
>   This is mainly relevant with local re-builds and pre-built packages
> where only some should be deployed to the isar-apt. I recently debugged
> such a case for an hour to understand why not the upstream package of
> ntpsec is used, but my broken custom-built one (which I removed but
> still lingered in the isar-apt)

Thanks for the specific aspects, we will look at that.

To my knowledge, at least the scheduler topic should not be an issue after
sbuild migration. Reproducibility and removal are technical issues that can be
improved, there is nothing inherently broken with the approach.


In general, we rely on Debian tooling for building packages and root
filesystems. Those, in turn, rely on apt. So, for Debian, apt repos are the
transfer mechanism. There are some aspects where Debian, being a distro and not
a development framework, shows its limitations for our use cases (version
number bumping, etc.). What I'd like to avoid is to create an inherently
source-based distribution disparate from Debian that emulates some deliverables
at the end; we should evaluate our use cases and look at enhancing Debian
workflows if necessary.


> PS: I cannot access the mentioned links, looks like your patchwork is
> down (or something is broken with our network).

Seems to be ok at least according to
https://downforeveryoneorjustme.com/patchwork.isar-build.org


With kind regards,
Baurzhan