[bug #61337] Modularity/dependence of basic software packages

[Boud Roukema]

Follow-up Comment #2, bug #61337 (project reproduce):

[comment #1 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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61337>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/