Re: [PATCH v2] dpkg-base: Remove newly deployed debs from buildchroots

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

On Mon, 17 Aug 2020 17:38:46 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 17.08.20 14:50, Henning Schild wrote:
> > On Tue, 11 Aug 2020 09:05:59 +0200
> > "[ext] Jan Kiszka" <jan.kiszka@siemens.com> wrote:
> >   
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> This ensures clean reinstallation after partial rebuilds.
> >>
> >> A typical error pattern so far was that firmware packages pulled by
> >> the buildchroot-target were not updated there on rebuilds, causing
> >> the old firmware being deployed into the image.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> ---
> >>
> >> Changes in v2:
> >>  - removed bogus -U options which sneaked in from reading the wrong
> >> man page (zypper's apt-get wrapper: -U, --no-clean-deps)
> >>
> >>  meta/classes/dpkg-base.bbclass | 12 +++++++++---
> >>  1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/dpkg-base.bbclass
> >> b/meta/classes/dpkg-base.bbclass index 9aa2d546..08880d7d 100644
> >> --- a/meta/classes/dpkg-base.bbclass
> >> +++ b/meta/classes/dpkg-base.bbclass
> >> @@ -154,20 +154,26 @@ python do_dpkg_build() {
> >>  
> >>  addtask dpkg_build before do_build
> >>  
> >> -CLEANFUNCS += "repo_clean"
> >> +CLEANFUNCS += "deb_clean"
> >>  
> >> -repo_clean() {
> >> +deb_clean() {
> >>      DEBS=$( find ${S}/.. -maxdepth 1 -name "*.deb" || [ ! -d ${S}
> >> ] ) if [ -n "${DEBS}" ]; then
> >>          for d in ${DEBS}; do
> >>              repo_del_package "${REPO_ISAR_DIR}"/"${DISTRO}" \
> >>                  "${REPO_ISAR_DB_DIR}"/"${DISTRO}"
> >> "${DEBDISTRONAME}" "${d}"
> >> +            package=$(basename "${d}")
> >> +            package_remove="/usr/bin/apt-get remove -y
> >> ${package%%_*}"
> >> +            sudo -E chroot ${BUILDCHROOT_DIR} ${package_remove} ||
> >> true  
> > 
> > This will cause serious headache when rebuilding essential packages.
> > You risk removing dpkg/apt and others.  
> 
> Not sure if that would already work, at least when the result actually
> targets the buildchroot and not just the device.

I am also not sure, especially when looking at the buildchroots.

> > 
> > I think we rather need an "apt-get upgrade --allow-downgrades"
> > together with a "apt-get autoremove" somewhere.  
> 
> I think those only work if the version number changed which is not
> guaranteed. We would need some switch that enforces re-installation,
> and that possibly only when some trigger tells us that the package has
> changed. apt-get reinstall?

Not changing the version number is probably bad style. I think one
should always change it when working on a recipe. While working on it
people hopefully know what to clean, and others merging changes will
simply get a proper rebuild with a new version.

> If we do not find a quick solution, I think such corner cases could
> also be addressed when needed. The current situation is too
> problematic to leave it like it us much longer.

Agreed, it could just be a made-up corner-case. Just wanted to point
out the potential danger and stress the fact that changed content
without changing the version is a bad idea.

Henning

> Jan
>