comment #1:

> When we find such hidden dependencies, we should indeed, add them in the Make prerequisite.

I don't think it's a good idea to add them unless we understand the full nature of the dependencies. In this case, I did not have the time to do that.

> But generally, even in the not yet version-updated 'maneage' branch, 'libbsd' depended on Coreutils directly! So I don't exactly understand how this situation occurred. What do you mean by "removing" coreutils? Did you just delete the target file in '.local/version-info'?

Quite likely yes, by "remove only coreutils", I seem to remember deleting .local/version-info/proglib/coreutils-* . It does seem likely to me that libbsd depends on coreutils in that version. That seems to imply that the dependence is more complicated - it could be an effect of installed libraries, or of libbsd depending on something else that depends on coreutils but whose dependence is not included in 'basic.mk'.

Doesn't coreutils provide command line tools, not just libraries? That would imply that any package that uses any of those tools might have different compilation behaviour if coreutils is updated.

> But in the future if you do find such cases and you notice that we have missed any dependency, please add it as a dependency and let us know to include in the 'maneage' branch ;-).

In this case, I noticed the bug, but didn't have the time or knowledge to try to find a solution. A blind systematic search would require making multiples copies of the full 5Gb or so .build/software/ directory, and then separately in each copy, removing, e.g. 2 or 3 or 4 or 5 of the 26 or so programs normally compiled earlier. That would make 26!/2!/24! + 26!/3!/23! + 26!/4!/22! + 26!/5!/21! = 83655 different heavy tests, which would really be exaggerating in terms of the CO2 equivalent footprint, and be impractical.

Solving these sorts of bugs requires good knowledge of each of the basic packages and their relations.

> Metastore (and the packages it depends on) is a high-level product that is
> only relevant during the project development (like Emacs!): when the user
> wants the file meta data (like dates) to be unchanged after checking out
> branches. So it should be considered a high-level software, not basic.
>
> It also usually causes many more headaches and error messages, so
> personally, I have stopped using it! Instead I simply merge my branches in

Metastore is disabled by default. It is opt-in, not opt-out.
See https://savannah.nongnu.org/bugs/?60376 .
It would be better to add the adjective "opt-in" in messages such as these, since
otherwise new users of Maneage will be confused.

This is a spinoff from https://savannah.nongnu.org/bugs/index.php?61026 . I think that this should probably be a perennial bug, unless we find a systematic way of solving it. It seems to me that we have always had this problem generically.

The problem is that if one of the 'basic.mk' software packages is removed, and './project configure --existing-conf' is run, quite often the build will fail because the 'make' rules in 'basic.mk' do not completely reflect the true dependences in our bootstrapping procedure. So the user either has to guess what other packages to remove, or has to do a completely fresh install (download/configure/compile/install = 'configure').

Tracing these bugs would probably require keeping the buggy installs frozen, and debugging them could be quite heavy.

61026 has one example:

(1) removing coreutils and doing './project configure --existing-conf' with coreutils-9.0 led to a 'libbsd' compile error, with some error lines listed at https://savannah.nongnu.org/bugs/index.php?61026 (Mon 04 Oct 2021 10:34:32 PM UTC, comment #7).

There is an associated error (that looks familiar) with mpfr:

make[3]: Entering directory '/BUILD/software/build-tmp/mpfr-4.0.2/tests'
make[4]: Entering directory '/BUILD/software/build-tmp/mpfr-4.0.2/tests'
FAIL: tversion
PASS: tabort_prec_max
PASS: tassert
PASS: tabort_defalloc1
PASS: tabort_defalloc2
...