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

[Jan Kiszka <jan.kiszka@siemens.com>]

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 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