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.
In the particular case of libbsd, in the current version updating, it has been moved to 'high-level.mk' as part of commit b8b1a534; commit message in the P.S.).
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'?
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 ;-).
P.S. Message of commit that moved metastore (and thus libbsd and libmd into the high-level set of packages):
|
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.
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:
|
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.