From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6834022395126218752 X-Received: by 2002:a05:600c:2246:: with SMTP id a6mr15423053wmm.71.1597678731557; Mon, 17 Aug 2020 08:38:51 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:b787:: with SMTP id h129ls7741452wmf.3.canary-gmail; Mon, 17 Aug 2020 08:38:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0PKGZDlrwX1V6bmxP7qgwPZB91/Mv2NYUOiQrSLtlC9g3jV1jiLVs+cUyZ5RLOwLkOgr6 X-Received: by 2002:a7b:ce0e:: with SMTP id m14mr15835437wmc.160.1597678730823; Mon, 17 Aug 2020 08:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597678730; cv=none; d=google.com; s=arc-20160816; b=HJTe++gVwR1kcnfLIx5M60UKX4yuk/2F5qCrms/p2djdlusektOiUhPMR/4BP/cQmw CP0HGVSeP3zbFacS7Acze+jqbSrAwOanSbOsihJ4myF0OEUzkhVWk3zqZF4zRarKcjUA BdSJkcgS0pYWsLC5bE7fDmq5u2Y92sOeb/1ntsy37c6zIzYnETm5hcmRQIeKVxndOvj/ cE46unXvyB983ggkBNh02uN6F/iscckavsoxfFKQSQpbw58j6wxCUar9CoD9klmWn0jt i+H4SeGu2tD2lrO8aXIxhIV+KiDIXPAbNd+7QDB3CCE/NZm0P10BwLew4gN7jRD7a+aR DoGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=T8yErcNhoHs20aYQIxPbMi9WyiWY2dC6ZNY27Muc2HU=; b=XZhH5mgYjgj6MYhlVYB5KTgJSjpHEUupY3kqtf72oJ0oeaqzFB5vrBPCti+6jWruIV WKuR8h+dQzlZLfPy7O/28IMzzzZ97/mbISRGHMRlOFwascaXdgasMggA+9+qVjE4X4TR VuNbmklsVuxLEuhZw7WnEdK3nqgp1xRfgnHBtykJI7d3pEn86ptiNj/04cSwWOaqI8l5 t61R6hhIdbhZHkxzIA3wrnAHtNcTXVIZvyfjU5BYO6VYDZHro2N/LelRs+93+W+F2kHk A+KbWw9ChYCyzbV0clL3ipdXnWnl0VuzXdOSfDihv7322XJ173pWLbkDaNyE1WDWvbUP 2tFA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@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 h11si726373wrc.2.2020.08.17.08.38.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 08:38:50 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@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 07HFcnvN031483 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Aug 2020 17:38:49 +0200 Received: from [167.87.134.109] ([167.87.134.109]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 07HFclwg017165; Mon, 17 Aug 2020 17:38:48 +0200 Subject: Re: [PATCH v2] dpkg-base: Remove newly deployed debs from buildchroots To: Henning Schild Cc: isar-users , Harald Seiler References: <20200817145050.6a6fc69a@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <96eea6bd-7d68-9850-0724-47e811113997@siemens.com> Date: Mon, 17 Aug 2020 17:38:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200817145050.6a6fc69a@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 8iwZfdgQwlUp 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 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? 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux