Re: [PATCH v10 00/19] Sbuild/Schroot migration

[Baurzhan Ismagulov <ibr@radix50.net>]

On Thu, May 12, 2022 at 03:55:19PM +0000, Moessbauer, Felix wrote:
> thanks for all the effort regarding the sbuild support.
> We tested that on a couple of layers and it mostly worked quite well.
> The following aspects are worth thinking about, but should not result in another delay in the integration of sbuild:

Thanks for the input, I also think we should find a good way to merge sbuild
soon.


> Removal of do_install_builddeps task: Please add a bold statement about that in the API changelog

The patch has been sent.


> Manual actions in a package schroot: Some layers (like meta-coral) require additional work to be done inside the buildchroot to prepare things prior to the debuild / sbuild.
> Mounting the correct schroot and working there works, but this is totally undocumented ground. We should really guide the ISAR users how to do that correctly (otherwise a ton of partially working patterns will evolve downstream).
> A public example, where this is necessary can be found in [1] (still pre-sbuild)

In short, we should avoid any buildchroot preparations. The Debian way is to
specify anything that is needed in the build dependencies, so that a dumb
package builder can build any package in a cleanroom environment without
knowing what is inside. We've done this for meta-iot2050.

This works well for Debian which doesn't have many flavors (except a couple of
kernels for x86 and arm). In the layers, we often want to customize stuff.
Currently I'm aware of the environment way (like DEB_BUILD_OPTIONS), but that
is handled in debian/rules; right now I don't know how to handle other stuff
like build dependencies. If you have specific examples, I think we should
discuss it with the upstream -- maybe they'd have suggestions, or we could
collaborate on improvements.

For the imagers, seems we'll have an schroot session API for now, but I'd
prefer not to extend it to sbuild if at all possible.


> Setup and teardown of schroots:
> The teardown should always be executed, no matter if the job was successful or not.
> Currently this is handled by shell-traps, but we should really think about simplifying that for the users.
> Either a post-task handler could be registered for cleanup, or we use bitbake functions which are called from python with a try / catch / finally pattern.
> Maybe @Adriaan can comment on that, as he has built up quite some experience around cleanups when working on the mount patch series.

Well, we do prefer python and try-catch. We've tried that with mount rework and
it works well. The issue is that downstreams are affected, and we couldn't find
an elegant way to migrate away from shell scripts in downstreams. Longer-term,
I think we'll have to do that, shell tasks are interfering with too much stuff.

Till then, I'm afraid we have to live with shell. And its error handling, is,
well, traps :) .


> Integration of other patch series:
> At least personally I would really prefer to see other patch series being merged first.
> Examples are: cachability improvements, sstate scripts, mounting of /dev/pts (at least the bugfix series).

Some of the stuff has been merged.


> It is likely that pre-sbuild ISAR will be around for quite some time as layers need time to adopt.
> 
> New ISAR release: Once Sbuilder is in, the old ISAR should be tagged and the in-flight version number of ISAR should be increased.

Which in-flight version number do you mean? I'm only aware of the release info
in /etc, which uses git to get the tag.


With kind regards,
Baurzhan.