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

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

On 17.08.20 19:21, Henning Schild wrote:
> 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.

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