bugManeage - 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: 

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.

Boud Roukema <boud>
Group Member
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):


Metastore (and thus libbsd and libmd) moved to highlevel

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
a separate clone, then pull the merge commit: in this way, the files of my
project aren't re-written during the checkout phase and therefore their
dates are untouched (which can conflict with Make's dates on configuration
files).


Mohammad Akhlaghi <makhlaghi>
Group administrator
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:


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
...



Boud Roukema <boud>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)
  •  

    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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code