From: "Bezdeka, Florian" <florian.bezdeka@siemens.com>
To: "amikan@ilbers.de" <amikan@ilbers.de>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
"Moessbauer, Felix" <felix.moessbauer@siemens.com>
Subject: Re: [PATCH(sbuild) 1/1] sbuild: Add changelog entry
Date: Wed, 18 May 2022 15:54:34 +0000 [thread overview]
Message-ID: <cd3393829a867615e5702a7b362cbe8cef523ad8.camel@siemens.com> (raw)
In-Reply-To: <20220518151237.2733-1-amikan@ilbers.de>
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
>
next prev parent reply other threads:[~2022-05-18 15:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 15:12 Anton Mikanovich
2022-05-18 15:54 ` Bezdeka, Florian [this message]
2022-05-18 16:03 ` Baurzhan Ismagulov
2022-05-18 16:10 ` Bezdeka, Florian
2022-05-27 8:21 ` Baurzhan Ismagulov
2022-05-18 16:54 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd3393829a867615e5702a7b362cbe8cef523ad8.camel@siemens.com \
--to=florian.bezdeka@siemens.com \
--cc=amikan@ilbers.de \
--cc=felix.moessbauer@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox