Maneage - Bugs: bug #61337, Modularity/dependence of basic...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61337: Modularity/dependence of basic software packages
Submitter: | Boud Roukema <boud> | ||
Submitted: | Tue 12 Oct 2021 11:50:40 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Enhancement | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Tue 18 Jan 2022 11:33:40 AM UTC, comment #2: |
Boud Roukema <boud>![]() |
Mon 17 Jan 2022 11:11:07 PM UTC, comment #1: When we find such hidden dependencies, we should indeed, add them in the Make prerequisite.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Tue 12 Oct 2021 11:50:40 PM UTC, original submission:
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.
|
Boud Roukema <boud>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
comment #1:
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.
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.
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 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.