Re: [PATCH(sbuild) 1/1] sbuild: Add changelog entry

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 18 May 2022 15:54:34 +0000
schrieb "Bezdeka, Florian" <florian.bezdeka@siemens.com>:

> On Wed, 2022-05-18 at 18:12 +0300, Anton Mikanovich wrote:
> > Migration from buildchroot to sbuild will cause API change.
> > Add changelog entry which also includes do_install_builddeps task
> > remove mentioning.  
> 
> Uh... Wait... Is that sbuild stuff already merged? 
> 
> I'm expecting quite some trouble in downstream layers when trying to
> update ISAR next time. I would vote for the following to avoid a
> "migrate all at once" scenario:
> 
> - Apply all pending patches (except sbuild stuff)
> - Prepare a new "stable release 0.9" and maintain that "branch" for
>   some time. 
> - branch out for ISAR 1.0, apply sbuild stuff there

Maybe one day we need such stable branches and releases. The question
is when and which breaking change will be the breaking change to really
upset users, and if they can effort to switch build systems after being
a little upset ;).

We are pretty slow in getting changes in, CI is way too slow and shaky,
no patchwork ... i think at the moment we are not remotely ready for a
second branch. That would need more infra and automation.

And honestly as a user and a dev i rather move with the flow, even if i
have breaking changes, trade new bugs for old ones ... A pure user or
mostly user might have a very different view, and we see layers getting
stuck on old isar because they can not keep up. While at the same time
others think isar is moving too slow. And the ones getting stuck often
do so because they forked, either really or by writing horrendous layers
which appended/removed/taskadded the hell out of isar.

As a dev that will also cause a lot of work. Write the patch for next,
get it merged ... backport it, test it again ...

I think we should assume that some day will be the day where we start
the branching, and should prepare for that day. But sbuilder is too
ready and that day still too far to do that now.

I really hope all the READMEs and stuff point users here to complain or
raise issues, and that someone keeps an eye on that github issue
tracker. While i hear the regular "isar changed again"/"isar is too
slow" sometimes ... people usually deal with it and are not really
upset. If users complain we should take that seriously, i am not sure
how many complaints we really got, feeling is we can bring a big
breaking change. In fact its main motivation is to improve also the
quality of the packaging, and speeding up the builds. So do the big
move and point out the benefits, people will understand and deal with
it.

Henning

> That would allow downstream layers to test and migrate in multiple
> iterations against the 1.0 release. I guess sbuild will discover some
> build problems. If layers have more such problems updating all at once
> can be hard.
> 
> Further ideas?
> 
> Best regards,
> Florian
> 
> > 
> > Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
> > ---
> >  RECIPE-API-CHANGELOG.md | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > index f3b3035..092292b 100644
> > --- a/RECIPE-API-CHANGELOG.md
> > +++ b/RECIPE-API-CHANGELOG.md
> > @@ -397,3 +397,16 @@ New conversions can be added by defining
> > CONVERSION_CMD_type.
> >      - the conversions appends its own type, e.g. the output file
> > of a conversion `xz` would be ${IMAGE_FULLNAME}.${type}.xz
> >      - a final chown is appended automatically
> > +
> > +### Buildchroot no longer used for package building
> > +
> > +Packages are now built with sbuild which takes care of dependency
> > +installation.
> > +The task do_install_builddeps has been removed.
> > +
> > +The migration to sbuild also means that all changes in the rootfs
> > made during +package building will not be shared between the build
> > sessions of different +packages and will be lost after a given
> > build session finishes. +
> > +Any package build requirements for the rootfs should be satisfied
> > in the +Debian way via package dependencies.
> > -- 
> > 2.17.1
> >   
>