upgrade from 18.04 to 20.04 fails to calculate if libomp5 is installed

I was able to recreate the failure to calculate the upgrade by installing the packages clang-6.0 and pocl-opencl-icd.

I uninstalled clang-6.0 and the update now seems to proceed fine. Thank you Brian!

The following bug reports may be duplicates of this bug.

 $ for log in $(find . -name VarLogDistupgradeAptlog.txt); do grep -H -m 1 "libomp5:amd64 rather than change libomp5-10:amd64" $log; done
./bug-1885521/VarLogDistupgradeAptlog.txt: Holding Back libomp5:amd64 rather than change libomp5-10:amd64
./bug-1885962/VarLogDistupgradeAptlog.txt: Holding Back libomp5:amd64 rather than change libomp5-10:amd64
./bug-1876395/VarLogDistupgradeAptlog.txt: Holding Back libomp5:amd64 rather than change libomp5-10:amd64
./bug-1876536/VarLogDistupgradeAptlog.txt: Holding Back libomp5:amd64 rather than change libomp5-10:amd64
./bug-1884791/VarLogDistupgradeAptlog.txt: Holding Back libomp5:amd64 rather than change libomp5-10:amd64

Removing libomp5 after adjusting sources.list from bionic to focal allows the upgrade to calculate.

bdmurray@clean-bionic-amd64:~$ sudo apt-get remove libomp5
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) libomp-dev:amd64 < 5.0.1-1 -> 1:10.0-50~exp1 @ii umU Ib >
Broken libomp-dev:amd64 Depends on libomp-10-dev:amd64 < none | 1:10.0.0-4ubuntu1 @un uH > (>= 10~)
  Considering libomp-10-dev:amd64 0 as a solution to libomp-dev:amd64 0
  Re-Instated libomp5-10:amd64
  Re-Instated gcc-10-base:amd64
  Re-Instated libgcc-s1:amd64
  Re-Instated libomp-10-dev:amd64
  Re-Instated libomp-dev:amd64
Done
The following additional packages will be installed:
  gcc-10-base libgcc-s1 libomp-10-dev libomp-dev libomp5-10
Suggested packages:
  libomp-10-doc
The following packages will be REMOVED:
  libomp5
The following NEW packages will be installed:
  gcc-10-base libgcc-s1 libomp-10-dev libomp5-10
The following packages will be upgraded:
  libomp-dev
1 upgraded, 4 newly installed, 1 to remove and 1409 not upgraded.
Need to get 411 kB of archives.
After this operation, 1,863 kB of additional disk space will be used.

Additionally, installing libomp5-10 right attempting the upgrade allowed the upgrade to calculate.

I confirm, it works with your solution Brian.
Thank you :-)

Modifying the Breaks: section of the packages file for libomp5-9 and libomp5-10 so that its "Breaks: (<< 3.7-1)" also allowed the upgrade to calculate so we could SRU llvm-toolchain-9 and llvm-toolchain-10 so that upgrades work without people having to do anything.

Julian suggested moving the clang-9 Recommends of libomp-9-dev to a Suggests and that also allowed the upgrade to complete.

Breaks without Replaces is highly unusual, and in this case a versioned Replaces in addition to the Breaks would be correct. It may help with the upgrade calculation.

I tested a release upgrade from bionic to focal with my PPA enabled which has version of libomp5-9 and libomp5-10 which Break and Replace on libomp5 (<<5.0.1-1). While the upgrade proceeded and succeeded libomp5 from bionic was still installed on the system.

root@clean-bionic-amd64:~# apt-cache policy libomp5
libomp5:
  Installed: 5.0.1-1
  Candidate: 1:10.0-50~exp1
  Version table:
     1:10.0-50~exp1 500
        500 http://192.168.10.7/ubuntu focal/universe amd64 Packages
 *** 5.0.1-1 100
        100 /var/lib/dpkg/status

Attached are log files from the upgraded.

I tested a second upgrade from bionic to focal with my PPA enabled and this time libomp5 was identified as an "Unused dependencies" and a "remove_candidates". However, this time it was actually marked for removal while previously this appeared in /var/log/dist-upgrade/main.log:

 2020-08-22 09:49:11,854 DEBUG package 'libomp5' produces an unwanted removal 'gnome-software-plugin-snap', skipping
 2020-08-22 09:49:12,751 DEBUG 'libomp5' scheduled for remove but not safe to remove, skipping

So I think the debian/control changes in the PPA work but something else is wrong with the release-upgrader and the snap removal work.

Actually, its nothing to with snaps - that package just has the word snap in it. So something seems wrong with the process which finds unwanted removals.

I've discovered what is wrong with the unwanted removals and that is tracked in bug 1894919.

Status changed to 'Confirmed' because the bug affects multiple users.

This is actually a bug with the llvm package relationships and not one with ubuntu-release-upgrader.

I installed clang-9 package, calculations of upgrade running fine.

I also installed clang-9, and calculation of upgrade is running fine. Finally I can update. Thank you all especially Brian-Murray.

Sorry i forget to thanks all support guys especially Brian-Murray.