New: package build failure when target install set to no on pkg-generic pkg types

https://bugs.busybox.net/show_bug.cgi?id=13836

Bug ID: 13836
Summary: package build failure when target install set to no on
pkg-generic pkg types
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: matthew.weber at rockwellcollins.com
CC: buildroot at uclibc.org
Target Milestone: ---

Here are the relevant assumptions/if's:

Buildroot 2021.02.x
( based on git log review, should also apply to master )

Package A is pkg-generic
Package A is the last "pkg-generic" package built
Package A has PACKAGE_A_INSTALL_TARGET = NO

Then this error occurs:
/bin/sh: /home/tbuild/myboard/build/package_a/.files-list.after: No such file or directory
make[1]: *** [/home/tbuild/myboard/build/package_a/.stamp_installed] Error 1
make: *** [_all] Error 2

because of assumptions with this target in rc-buildroot/package/pkg-generic.mk:
# Final installation step, completed when all installation steps
# (host, images, staging, target) have completed $(BUILD_DIR)/%/.stamp_installed:

        @$(call pkg_size_after,$(TARGET_DIR))
        @$(call pkg_size_after,$(STAGING_DIR),-staging)
        @$(call pkg_size_after,$(HOST_DIR),-host)
        @$(call check_bin_arch)
        $(Q)touch $@

Ugly solution that worked:
simply remove the PACKAGE_A_INSTALL_TARGET = NO

Possible solution:

1) use a package type other than pkg-generic?
2) change the buildroot logic to subtract INSTALL_TARGET = NO packages from this target build step.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=13836

Yann E. MORIN <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |yann.morin.1998 at free.fr
             Status|NEW                         |ASSIGNED

--- Comment #1 from Yann E. MORIN <[email protected]> --- Matt, All,

I could indeed replicate with just;

PACKAGE_A_SOURCE =
PACKAGE_A_INSTALL_TARGET = NO
$(eval $(generic-package))

However,m this is not specific to generic-package; it also happens with autotools-package (I tested), and I suppose with any of our package infras (untested, but I fail to see why it swould not).

Also, it occurs even if said package is not the last.

However, it only occurs in the situation where a package does not want to be installed in target, but does not request being installed in staging or images either. If the package installs to one or more of those locations, then there is no error. That is, it's a package that does not install anything at all, anywhere at all.

In this case, the package does not even get downloaded, patched, configured, or built.

Does it even make sense at all to begin with? Shouldn't we detect that situation instead, and error out with a better error message?

Regards,
Yann E. MORIN.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=13836

--- Comment #2 from Yann E. MORIN <[email protected]> --- Matt, All,

I was thinking a proper solution to the issue would be something along the lines of:

```diff
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 9fbc63d19e..5e53d008e1 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -1120,6 +1120,12 @@ endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
 # configuration
 ifeq ($$($$($(2)_KCONFIG_VAR)),y)

+ifeq ($$($(2)_TYPE),target)
+ifeq ($$(filter YES,$$($(2)_INSTALL_STAGING) $$($(2)_INSTALL_IMAGES)
$$($(2)_INSTALL_TARGET)),)
+$$(error $(1) does not install anything anywhere)
+endif
+endif
+
 # Ensure the calling package is the declared provider for all the virtual
 # packages it claims to be an implementation of.
 ifneq ($$($(2)_PROVIDES),)
```

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=13836

--- Comment #3 from Yann E. MORIN <[email protected]> --- Matt, All,

Turned out, that the fix is pretty trivial, but the causes are really not that simple:

https://patchwork.ozlabs.org/project/buildroot/patch/20210613143207.2445691-1-yann.morin.1998 at free.fr/

Thanks for the report!

Regards,
Yann E. MORIN.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=13836

Yann E. MORIN <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Yann E. MORIN <[email protected]> --- Matt, All,

Thanks for the report.

We believe this is now fixed with commit ee5e14ff17fd (core/pkg-generic: fix instrumentation for packages that install nowhere) that was just pushed.

Regards,
Yann E. MORIN.

You are receiving this mail because:
You are on the CC list for the bug.