Bug 750041 – sys-apps/portage: failed emerge invocations can leave the system in an broken state that can cause later emerge invocations to fail unless emerge --update --deep is used

• Status: CONFIRMED
• Product: Portage Development

[Description Hank Leininger 2020-10-19 03:19:18 UTC]

tl;dr: $Summary

On a particular system, I had over previous months/weeks done:

- upgrade ocaml to dev-lang/ocaml-4.09.0
- upgrade camomile to dev-ml/camomile-0.8.5-r2
- upgrade ocaml-fileutils to dev-ml/ocaml-fileutils-0.6.2
- upgrade ocaml-gettext to dev-ml/ocaml-gettext-0.3.7-r1

and then...
- upgrade ocaml to dev-lang/ocaml-4.11.1
- attempt to upgrade ocaml-gettext to dev-ml/ocaml-gettext-0.4.2

That build failed with:

 >>> Compiling source in /var/tmp/portage/dev-ml/ocaml-gettext-0.4.2/work/ocaml-gettext-0.4.2 ...
   ocamlyacc src/lib/gettext/base/gettextMo_parser.{ml,mli}
14 shift/reduce conflicts.
   ocamlyacc src/lib/gettext/extension/gettextPo_parser.{ml,mli}
12 shift/reduce conflicts.
File "src/lib/gettext/extension/gettextDomain.ml", line 1:
Error: /usr/lib64/ocaml/fileutils/FilePath.cmi
       is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.

That file is provided by ocaml-fileutils, which had not been rebuilt since the ocaml upgrade. Rebuilding dev-ml/ocaml-fileutils-0.6.2 made it possible to build the updated ocaml-gettext.

Many dev-ml/ packages already specify an RDEPEND of dev-lang/ocaml:=, so they are automatically rebuilt if ocaml upgrades; it looks to me like ocaml-fileutils needs to do the same.

Note, this got indirectly fixed when other packages got their deps updated to be dev-lang/ocaml:=, so trying to upgrade to ocaml-4.11.1 results in updating other things and triggering a rebuild of ocaml-fileutils. I have to go out of my way to reproduce this problem w/my currently installed set of packages. So maybe this is already moot as of the tree ~yesterday.

[Comment 1 Sam James 2020-10-19 03:26:12 UTC]

We may have a problem here: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/dune.eclass#n28

> RDEPEND=">=dev-lang/ocaml-4:=[ocamlopt?]"

I wonder if it just failed to get around to rebuilding it or if it completely missed the need to rebuild it.

The former is a really irritating known likely-bug: bug 625160.

We should probably have a subslot exposed in its dependency stdlib-shims at least, and possibly ounit (I think it gets built against, not just used for running). But I don't know if this would have fixed the problem...

I'll CC dev-portage@ because this recurring set of issues with rebuilds not happening, for one reason or another, is concerning, but I might be missing something obvious in this particular case too.

[Comment 2 Zac Medico 2020-10-19 04:12:11 UTC]

(In reply to Hank Leininger from comment #0)
> tl;dr: $Summary
> 
> On a particular system, I had over previous months/weeks done:
> 
> - upgrade ocaml to dev-lang/ocaml-4.09.0
> - upgrade camomile to dev-ml/camomile-0.8.5-r2
> - upgrade ocaml-fileutils to dev-ml/ocaml-fileutils-0.6.2
> - upgrade ocaml-gettext to dev-ml/ocaml-gettext-0.3.7-r1
> 
> and then...
> - upgrade ocaml to dev-lang/ocaml-4.11.1

Can we see the portion of your /var/log/emerge.log corresponding to the dev-lang/ocaml-4.11.1 upgrade?

[Comment 3 Hank Leininger 2020-10-19 22:16:38 UTC]

(In reply to Zac Medico from comment #2)
> (In reply to Hank Leininger from comment #0)
> > tl;dr: $Summary
> > 
> > On a particular system, I had over previous months/weeks done:
> > 
> > - upgrade ocaml to dev-lang/ocaml-4.09.0
> > - upgrade camomile to dev-ml/camomile-0.8.5-r2
> > - upgrade ocaml-fileutils to dev-ml/ocaml-fileutils-0.6.2
> > - upgrade ocaml-gettext to dev-ml/ocaml-gettext-0.3.7-r1
> > 
> > and then...
> > - upgrade ocaml to dev-lang/ocaml-4.11.1
> 
> Can we see the portion of your /var/log/emerge.log corresponding to the
> dev-lang/ocaml-4.11.1 upgrade?

Sure, I'll attach a slightly pruned/redacted version of:

egrep 'Started emerge on:| \*\*\* |dev-lang/ocaml|dev-ml/' /var/log/emerge.log | egrep -B2 -A1000 'dev-lang/ocaml-4\.1' >~/emerge_ocaml.log

[Comment 4 Hank Leininger 2020-10-19 22:18:27 UTC]

Created attachment 667214 [details]
Log of ocaml emerges starting with dev-lang/ocaml-4.11.1

[Comment 5 Zac Medico 2020-10-19 23:08:42 UTC]

(In reply to Hank Leininger from comment #4)
> Created attachment 667214 [details]
> Log of ocaml emerges starting with dev-lang/ocaml-4.11.1

The dev-ml/ocaml-fileutils-0.6.2 rebuild would have been scheduled during the emerge invocation that upgraded dev-lang/ocaml-4.11.1. However, that emerge invocation exited prematurely here:

1602879477:  === (102 of 269) Cleaning (dev-ml/camomile-0.8.5-r2::[snip]/camomile-0.8.5-r2.ebuild)
1602879477:  === (102 of 269) Compiling/Merging (dev-ml/camomile-0.8.5-r2::[snip]/camomile-0.8.5-r2.ebuild)
1602879492:  *** Finished. Cleaning up...
1602879492:  *** exiting unsuccessfully with status '1'.
1602879498:  *** terminating.

Then you ran this command which is does not emerge options that would trigger that rebuild:

1603062122: Started emerge on: Oct 18, 2020 17:02:01
1603062122:  *** emerge --oneshot --ask --regex-search-auto=y --verbose camomile ocaml-gettext

You need to use the --deep option in order to account for dependencies of installed packages.

[Comment 6 Hank Leininger 2020-10-19 23:15:06 UTC]

(In reply to Zac Medico from comment #5)
> (In reply to Hank Leininger from comment #4)
> > Created attachment 667214 [details]
> > Log of ocaml emerges starting with dev-lang/ocaml-4.11.1
> 
> The dev-ml/ocaml-fileutils-0.6.2 rebuild would have been scheduled during
> the emerge invocation that upgraded dev-lang/ocaml-4.11.1. However, that
> emerge invocation exited prematurely here:
[snip]
> 
> Then you ran this command which is does not emerge options that would
> trigger that rebuild:
> 
> 1603062122: Started emerge on: Oct 18, 2020 17:02:01
> 1603062122:  *** emerge --oneshot --ask --regex-search-auto=y --verbose
> camomile ocaml-gettext
> 
> You need to use the --deep option in order to account for dependencies of
> installed packages.

Aha, good call!

When trying again to get past something that failed during a world update, I am not in the habit of including --deep to try again on the fixed things. I need to be!

Thank you for looking.