From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Mon, 21 Jun 2021 22:18:49 +0200 Subject: [Buildroot] [PATCH] core/pkg-generic: fix instrumentation for packages that install nowhere In-Reply-To: <20210613143207.2445691-1-yann.morin.1998@free.fr> (Yann E. MORIN's message of "Sun, 13 Jun 2021 16:32:07 +0200") References: <20210613143207.2445691-1-yann.morin.1998@free.fr> Message-ID: <87im277yza.fsf@dell.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Yann" == Yann E MORIN writes: > A (target [0]) package can independently declare installing in various > locations: target, staging, or images. The default is to only install > in target. > When a package opts out from installing to target, but does not opts > in to install in any other location, the package is not downloaded, > extracted, patched, configured, nor built at all. As a consequence, none > of the per-step instrumentation is not executed, specifically the > listing of files before/after the package sequence. > Down the line, the package infra does not cope well with that situation, > because the gathering-install step, the one that synchronises all the > optional target, staging, or images install steps, still gets run. > And as #13836 shows, this does not go well: > /bin/sh: /home/tbuild/myboard/build/foo/.files-list.after: No such file or directory > make[1]: *** [/home/tbuild/myboard/build/foo/.stamp_installed] Error 1 > make: *** [_all] Error 2 > So, we should have ensured that the gathering-install step itself > depends on the build step, which would have solved the issue. > However, this bug really illustrates a more fundamental issue: does it > even make sense to have a package that installs nothing in any location? > Indeed, why even bother with that package to begin with if it will not > provide anything at all? > It turns out that yes, this makes sense. We have some packages, that > do not install anything at all, and do not even build anything; they are > there just to ensure that we can download something that will ultimately > be used by another package. This is the case for example for packages > that provide linux extensions, like aufs [1]. > Additionally, some ugly out-of-tree packages could conceivably install > things during the build (or even configure!) steps. That's not unheard > of... [2] > So, the solution is to ensure that the gathering-install step does > depend on the build step, to trigger the proper dependency chain and > have the instrumentation hooks properly run even in that degenerate > case. > Fixes: #13836 > [0] a host package can't opt out of installing anything. > [1] that one is actually missing AUFS_INSTALL_TARGET = NO, so this > hides the issue. > [2] even us are not 100% clean on that topic: gcc will install files in > staging and target as part of the same step (not the build, granted, > but still...) > Reported-by: "Weber, Matthew L Collins" > Signed-off-by: Yann E. MORIN > Cc: Thomas Petazzoni Committed to 2021.02.x and 2021.05.x, thanks. -- Bye, Peter Korsgaard