From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6834022395126218752 X-Received: by 2002:a1c:3dd6:: with SMTP id k205mr16103516wma.61.1597684885932; Mon, 17 Aug 2020 10:21:25 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:3802:: with SMTP id f2ls7872213wma.0.canary-gmail; Mon, 17 Aug 2020 10:21:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1bwYo2uFNuh3heKly5mcQ90xmjx9otg7sstOpKJqx69PcyX6GbPAXIaB0sUEY3Q0xPwjl X-Received: by 2002:a7b:cb17:: with SMTP id u23mr15741297wmj.79.1597684885023; Mon, 17 Aug 2020 10:21:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597684885; cv=none; d=google.com; s=arc-20160816; b=AlAeCFs6744XBYgmXFckbC/K6juFyPRu6gwXf+zKwtcFQk5cozIJdHI8fm1euvc6SH D4KDL6CskdjbUvQHoXCmzTWEM7aaeNCXT/Tg1hWnBkO4tSyrFfhoMfGEKsCe0r9cDKI9 12tBnHctqFxKrFVA9F3u2aVOH40YG9cbZ11X7TzBOLzql5s9xrymVXDUavLIv+PIvBzv uFeiikOVt36DNDs9kzU11sC83NVjmerRP3PetBVRAjwnVoDaftZYljOBhdVCvpNCTKFA JFJmPT7gHMO4NP6WrwpGwryHwKnBHnjQlAvrpZ6w+aVZ6AYkAsfXnu4Vh3/5Xwgc829o Y8KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=+6xdgYBu38PhZILyyF3akcaWaFTSCSTdn3Ail5A+9jg=; b=Zr8yNYnyYsYZ8aI9yXE3kZZ3QwMcRGTx8koKEf+XNHiNypdLWfPfksYivXOQY6qh/p zrHgOpbeRV5EYN4OtBiEztA0+fBf2gb/+o3xNh6xVMeabhuQcdUQRJdNI7iiqTJqQXGD k6eHK5t98LM2beH/RD3byWT/5Oybz62jfmpMMNf8OGCqoGtFtxqL/9ktjMxDEMQbPHWr L/qoFLQacLCCQQ/kEw7UiTYHpaSbSseS/UXqt8trMMBDbpepAcxwrGIaftPG6ezW/YZ4 /HUQpuWrwQRMFIRPy570ILi+dU/cNEePKRRNtm0Tu7ZGuxJivyqbrXXPdHanFaeU2L3n 2hrw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id n129si730470wma.2.2020.08.17.10.21.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 10:21:25 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 07HHLON5029956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Aug 2020 19:21:24 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.34.238]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 07HHLOiO028397; Mon, 17 Aug 2020 19:21:24 +0200 Date: Mon, 17 Aug 2020 19:21:22 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users , Harald Seiler Subject: Re: [PATCH v2] dpkg-base: Remove newly deployed debs from buildchroots Message-ID: <20200817192122.2c75051f@md1za8fc.ad001.siemens.net> In-Reply-To: <96eea6bd-7d68-9850-0724-47e811113997@siemens.com> References: <20200817145050.6a6fc69a@md1za8fc.ad001.siemens.net> <96eea6bd-7d68-9850-0724-47e811113997@siemens.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 4EKwAR6ENs+Z On Mon, 17 Aug 2020 17:38:46 +0200 Jan Kiszka wrote: > On 17.08.20 14:50, Henning Schild wrote: > > On Tue, 11 Aug 2020 09:05:59 +0200 > > "[ext] Jan Kiszka" wrote: > > > >> From: Jan Kiszka > >> > >> 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 > >> --- > >> > >> 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 >