From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6834022395126218752 X-Received: by 2002:a1c:1d52:: with SMTP id d79mr18685282wmd.82.1597730017112; Mon, 17 Aug 2020 22:53:37 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:2356:: with SMTP id j83ls553850wmj.1.canary-gmail; Mon, 17 Aug 2020 22:53:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/125nSQdPCeA2Jp4yVx7sHiFUZVLjt0zZlcl36Lnr1oX+bRk/bNjsq8v6DSxbT9VCR1B6 X-Received: by 2002:a1c:1bc4:: with SMTP id b187mr17567503wmb.175.1597730016321; Mon, 17 Aug 2020 22:53:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597730016; cv=none; d=google.com; s=arc-20160816; b=BD5xL6cx0qwAT0NnKJoW6dOhnr2C8Hl613bHT+munUgtLEnq/MM3b+D4BL9RGiJWj9 DoDkJbgDDiRzxYwFmeU6J6dluj0kLQkVTICaGHwy1nJYP/TiVEVnlWvFdbIKCniRoQTR +KvAHW50z7MOx3DPo+hKg+6dT3olS8DvUpHV5VEt3mZko15XIAzsPVYdnGkXVD0Sgp6W bHkihFTIlYJx58IebPH+n3RwtwW2zeatQ2Icu9F269UmIezs7whj2M6xEskbUE+WlBdj 3MFoh4sU9tOMTfDukNXuRmVcg9s/gLRilKrFA+UbIP/nAGyjaa6XtCc8bxF9qiZmn4Wp 64pQ== 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=fRcffMIYb0WYp41+yqt8S0C2YPZPHNB3vd2NQWHyjcM=; b=UuY1yB2d5pYFMYvqefDRUxnSfd1kTYTd5pvcufjD220rl/l02+Ox4xggIKAfYVzwmA gRASVst0VoxaublDTFqUa4Cr0GsPosRQDHIVC4Vy/wUUrVGAkraYWE/7cAnhvjt97kwP fxHqU8TaX/jmvyTzUtE79H3p0X+1rYCiFlKBIRPasNT4lsw4B/unEWslOCEdi5sU8EPQ +WLYjc0s8GKqgZa4MtHY3Xv3b9lQFlTH3f8otWuHI+cQDPzuMWUvL/WI0+5Q1vd6A4CH M4dxztWo4ynfMkeJIgZ78HPt89mH60ScO+qMtpRbifmYzSC9+1NATE5UZZrvDQE2rTJE 04jg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 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 goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id f134si50362wme.4.2020.08.17.22.53.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 22:53:36 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 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 goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 07I5rZFr019443 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Aug 2020 07:53:35 +0200 Received: from [139.22.40.250] ([139.22.40.250]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 07I5rYsQ017546; Tue, 18 Aug 2020 07:53:34 +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> <96eea6bd-7d68-9850-0724-47e811113997@siemens.com> <20200817192122.2c75051f@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <7b89ed0d-9acb-7b13-ade6-f02a257facde@siemens.com> Date: Tue, 18 Aug 2020 07:53:34 +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: <20200817192122.2c75051f@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: jizD/2+kqXiZ On 17.08.20 19:21, Henning Schild wrote: > 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. We've discussed this too often: This is not how people work, and it also makes zero sense for a local development cycle to continuously bump version numbers. Jan > >> 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 >> > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux