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

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

[Anton Mikanovich]

Migration from buildchroot to sbuild will cause API change.
Add changelog entry which also includes do_install_builddeps task
remove mentioning.

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

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

[Bezdeka, Florian]

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

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
> 

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

[Baurzhan Ismagulov]

On Wed, May 18, 2022 at 03:54:34PM +0000, Bezdeka, Florian wrote:
> 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
> 
> 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.

The sbuild series has not been merged yet. We are thinking how to handle this
and will continue the discussion.

In short, "all pending patches" is quite a moving target, there will always be
patches that are important. That said, many of the recently requested ones have
been merged. Maintaining a stable version for some time is not an easy decision
due to the effort and has to be carefully considered.

With kind regards,
Baurzhan.

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

[Bezdeka, Florian]

On Wed, 2022-05-18 at 18:03 +0200, Baurzhan Ismagulov wrote:
> On Wed, May 18, 2022 at 03:54:34PM +0000, Bezdeka, Florian wrote:
> > 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
> > 
> > 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.
> 
> The sbuild series has not been merged yet. We are thinking how to handle this
> and will continue the discussion.
> 
> In short, "all pending patches" is quite a moving target, there will always be
> patches that are important. That said, many of the recently requested ones have
> been merged. Maintaining a stable version for some time is not an easy decision
> due to the effort and has to be carefully considered.

Adding back some CCs so colleagues are notified as well. At least I'm
interested in this discussion.

> 
> With kind regards,
> Baurzhan.
> 

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

[Baurzhan Ismagulov]

On Wed, May 18, 2022 at 04:10:25PM +0000, Bezdeka, Florian wrote:
> Adding back some CCs so colleagues are notified as well. At least I'm
> interested in this discussion.

We've discussed this also with Jan, his suggestion is to release Isar 0.9
(feature freeze, decide fixes on per-patch basis), no stable branch, apply
sbuild after the release. If nothing else speaks against that, I'll be
proceeding in that way, the goal being to release rather sooner than later. I
have one hello build failure on my radar (no fix yet); if there are other
specific changes for the release, please let me know.

With kind regards,
Baurzhan.

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

[Henning Schild]

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
> >   
>