bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[bokr@oz.net]

Hi Danny,

On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote:
> How do I debug this?
> 
> $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure grep
> 
> needs grep (it's in the implicit native inputs), and that grep has a test failure.

What if the test failure tested a grep feature that you don't actually need from the implicit native input grep?

Is there no way to use a fully valid subset of a tool's functionality (that excludes irrelevant test failures
of unused broken functionality) if there's a test failure in testing everything?

If one could express a dependency on a limited subset by passing also a required-features list, à la ACL?,
maybe dependencies could trigger less builds, and the feature lists might reveal opportunities
for optimizing out some dependencies, e.g. where a bash shell's one or two grep invocations might
depend on grep only for a regex match that might easily be rewritten with bash's own built-in '=~'

One could imagine builds producing ELFs with bitvectors flagging features built and tested,
for efficient dynamic safe-capability determination re usage by dependents, but I better stop rambling.

So, monolith dependencies vs factoring, how to balance?

> 
> So I can't actually enter the environment for building grep and running
> 
>    make check
> 
> .
> 
> What now?

HTWNEU -- Hope This Was Not Entirely Useless :)
-- 
Regards,
Bengt Richter