[FIX] 15.0: purge apt data in the same layer as install

[ap-wtioit]

RUN apt-get purge -yqq $build_deps \
    && apt-get autopurge -yqq \
    && rm -Rf /var/lib/apt/lists/* /tmp/*

Does not make sense from docker layer perspective if it's not run in the same layer as the install. It also does not make sense from a shell perspective if $build_deps is not set for apt-get purge -yqq $build_deps.

With 21b8bde#diff-32129c0c5001d86cef22a1cecd12993dd630e851a67b5d286cef38b2399ac96bR170-R173 it seems build_deps are no longer removed after components are built and installed.

If this behaviour is required in TT54577 (it's always hard to assume what the issues are you are experiencing if the description is pretty empty: #644) do not merge this and if possible/allowed tell us what the issue was.

For us the change broke the efficiency test for a image cleanup script as image size for our cleaned up image. It goes from 1.1G to 2.2G with the previous PR (propably because the build_deps do no longer get removed in 15.0).

Info @wt-io-it

[josep-tecnativa]

Hi @ap-wtioit , this was not a requirement of that task, it was simply an error. Thanks for the PR!

[pedrobaeza]

@ap-wtioit it seems there's an error in the 15.0 test

[ap-wtioit]

@pedrobaeza that's a segfault when installing python 3.9, https://github.com/Tecnativa/doodba/actions/runs/13671225079/job/38224258049?pr=646#step:10:6158 in [linux/arm64 base 2/13]:

#9 314.2 Setting up python3 (3.9.2-3) ...
#9 314.3 running python rtupdate hooks for python3.9...
#9 314.3 running python post-rtupdate hooks for python3.9...
#9 315.1 Segmentation fault (core dumped)
#9 315.2 dpkg: error processing package python3 (--configure):
#9 315.2  installed python3 package post-installation script subprocess returned error exit status 139

that then caused npm not to be installed because it depends on python3.9

 #9 316.5 Setting up node-fs-write-stream-atomic (1.0.10-4) ...
#9 316.5 dpkg: dependency problems prevent configuration of gyp:
#9 316.5  gyp depends on python3:any; however:
#9 316.5   Package python3 is not configured yet.
#9 316.5 
#9 316.5 dpkg: error processing package gyp (--configure):
#9 316.5  dependency problems - leaving unconfigured
#9 316.5 dpkg: dependency problems prevent configuration of python3-pkg-resources:
#9 316.5  python3-pkg-resources depends on python3:any; however:
#9 316.5   Package python3 is not configured yet.
#9 316.5 
#9 316.5 dpkg: error processing package python3-pkg-resources (--configure):
#9 316.5  dependency problems - leaving unconfigured
...
#9 316.8 Setting up node-which (2.0.2+~cs1.3.2-1) ...
#9 316.8 dpkg: dependency problems prevent configuration of node-gyp:
#9 316.8  node-gyp depends on gyp (>= 0.1+20200513gitcaa6002); however:
#9 316.8   Package gyp is not configured yet.
#9 316.8 
#9 316.8 dpkg: error processing package node-gyp (--configure):
#9 316.8  dependency problems - leaving unconfigured
...
#9 316.9 Setting up libavformat58:arm64 (7:4.3.8-0+deb11u3) ...
#9 317.0 dpkg: dependency problems prevent configuration of npm:
#9 317.0  npm depends on node-gyp (>= 3.6.2~); however:
#9 317.0   Package node-gyp is not configured yet.
#9 317.0 
#9 317.0 dpkg: error processing package npm (--configure):
#9 317.0  dependency problems - leaving unconfigured
...
#9 317.7 Errors were encountered while processing:
#9 317.7  python3
#9 317.7  gyp
#9 317.7  python3-pkg-resources
#9 317.7  node-gyp
#9 317.7  npm

I'm not the expert regarding github actions (we are using gitlab CI) but i will try to check how the build is triggered and what happens there.

[ap-wtioit]

running the arm builds locally with qemu (prepared with docker run --rm --privileged multiarch/qemu-user-static --reset -p yes ):

docker build --platform linux/arm64 --target base -f 15.0.Dockerfile .

i get a different error every time (segfaults / compilation errors) and it took me 3 tries to get a build through, so i think it's fair to say 15.0 doodba builds for ARM are not stable (at least with multiarch/qemu-user-static)

[josep-tecnativa]

running the arm builds locally with qemu (prepared with docker run --rm --privileged multiarch/qemu-user-static --reset -p yes ):

docker build --platform linux/arm64 --target base -f 15.0.Dockerfile .

i get a different error every time (segfaults / compilation errors) and it took me 3 tries to get a build through, so i think it's fair to say 15.0 doodba builds for ARM are not stable (at least with multiarch/qemu-user-static)

I agree with you. It took me lots of tries to make it green, and in the end, it seems that it passed by chance due to the error of doing the purge separately.

Maybe @PCatinean, who made this PR #573, could take a look.

[josep-tecnativa]

Merged, although we must remember that arm build appears to be unstable with v15.