dotnet-sdk-2.1 package for OpenSUSE is broken

[wli3]

From @pavelbraginskiy on July 26, 2018 2:31

I don't know if this is the correct repo for this issue, but I can't think of a better place.

Steps to reproduce

Attempt to install .NET Core on OpenSUSE Tumbleweed following the instructions at https://www.microsoft.com/net/learn/get-started-with-dotnet-tutorial

Expected behavior

$ sudo zypper install dotnet-sdk-2.1
[sudo] password for root: 
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 6 NEW packages are going to be installed:
  aspnetcore-runtime-2.1 dotnet-host dotnet-hostfxr-2.1 dotnet-runtime-2.1 dotnet-runtime-deps-2.1 dotnet-sdk-2.1

6 new packages to install.
Overall download size: 163.1 MiB. Already cached: 0 B. After the operation, additional 163.1 MiB will be used.
Continue? [y/n/...? shows all options] (y):

Actual behavior

$ sudo zypper install dotnet-sdk-2.1
[sudo] password for root: 
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides libicu52_1 needed by dotnet-runtime-deps-2.1-2.1.2-1.x86_64
 Solution 1: do not install dotnet-sdk-2.1-2.1.302-1.x86_64
 Solution 2: break dotnet-runtime-deps-2.1-2.1.2-1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): 2
Resolving dependencies...
Resolving package dependencies...

The following 6 NEW packages are going to be installed:
  aspnetcore-runtime-2.1 dotnet-host dotnet-hostfxr-2.1 dotnet-runtime-2.1 dotnet-runtime-deps-2.1 dotnet-sdk-2.1

6 new packages to install.
Overall download size: 163.1 MiB. Already cached: 0 B. After the operation, additional 163.1 MiB will be used.
Continue? [y/n/...? shows all options] (y):

Environment data

dotnet --info output:

FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
   at System.Globalization.GlobalizationMode..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.CultureInfo..cctor()
   at System.StringComparer..cctor()
   at System.AppDomain.InitializeCompatibilityFlags()
   at System.AppDomain.Setup(System.Object)
[1]    3049 abort (core dumped)  TERM=xterm dotnet --info

dotnet --info output after setting System.Globalization.Invariant:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:    9048955601

Runtime Environment:
 OS Name:     opensuse-tumbleweed
 OS Version:  20180723
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.302/

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  2.1.302 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Copied from original issue: dotnet/cli#9735

[wli3]

From @nguerrera on July 28, 2018 15:22

@wli3

[wli3]

From @nguerrera on July 28, 2018 15:24

I assume there is a libicu package available for OpenSUSE that you can install to run without going to invariant mode where several features of the runtime will not work as you might expect. But I don't understand why the runtime package didn't pull it in for you.

@wli3 Who's a good contact for a missing runtime dependency in OpenSUSE package?

[wli3]

From @pavelbraginskiy on July 28, 2018 15:28

There is a libicu, but it has a different version number in the package name. dotnet doesn't detect it.

[wli3]

From @nguerrera on July 28, 2018 15:52

@janvorli Is this an issue in coreclr locating libicu? I'm totally guessing here, but I saw in https://github.com/dotnet/coreclr/pull/15562/files that there is some special code to handle the binding.

[wli3]

From @janvorli on July 29, 2018 17:15

@nguerrera this is a problem of the package. Coreclr can run with any libicu version higher or equal to 50, but the package that @pavelbraginskiy is trying to install refers to a version different from the one supported on the tumbleweed. It seems that our instructions describe single feed for opensuse 42.2, which cannot work for tubleweed. It is always possible to install the .tar.gz version that should work with any icu version installed.

[wli3]

From @nguerrera on July 29, 2018 17:39

cc @leecow

Should we recommend the .tar.gz for tumbleweed in the instructions or provide an additional feed there that can satisfy the libicu dependency?

[wli3]

From @nguerrera on July 29, 2018 17:42

Reading again it seems we're manifesting that we need icu 52 when 50 or greater would work. Should we be changing the package to allow a lower version?

[wli3]

@karajas @rakeshsinghranchi

[rakeshsinghranchi]

@nguerrera this is a problem of the package. Coreclr can run with any libicu version higher or equal to 50, but the package that @pavelbraginskiy is trying to install refers to a version different from the one supported on the tumbleweed. It seems that our instructions describe single feed for opensuse 42.2, which cannot work for tubleweed. It is always possible to install the .tar.gz version that should work with any icu version installed.
This looks like the reason for the failure. There are three options,

1. Update Runtime-Deps for opensuse 42.2 to use libicu50
2. Setup opensuse tumbleweed specific with runtime-deps exhibiting dependency for libicu50
3. Update installation guidance for tumbleweed to use .tar.gz as recommended by @wli3
   cc @leecow

[leecow]

I'm reluctant to produce an installer for Tumbleweed. Its rolling nature would have us chasing our tails keeping up with dependencies. Installing from tar.gz should be the plan but even that does not work at the moment. The libicu version available on Tumbleweed is libicu-suse61_1 and even after installing that, dotnet fails to locate what it believes is a valid ICU package.

[janvorli]

That is strange, that would indicate that there is something unexpected in the version 61.1. That version is still in the range of versions we scan. I can take a look over I'm back from my vacation in mid August. But of anyone else want to take a look now, it should be simple to find what's wrong by stepping through the code of the shim initialization code in icushim.cpp

[LukeTOBrien]

Could the official documentation for installing the SDK on OpenSuse be updated to say that currently only Leap is supported?

[Fisiu]

It doesn't work with Leap 15.0. During install it screams about libicu...

zypper in dotnet-sdk-2.1
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides libicu52_1 needed by dotnet-runtime-deps-2.1-2.1.2-1.x86_64
 Solution 1: do not install dotnet-sdk-2.1-2.1.400-1.x86_64
 Solution 2: break dotnet-runtime-deps-2.1-2.1.2-1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c):

Here is Leap info:

fisiu@pendrak:~ $ cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.0"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.0"
PRETTY_NAME="openSUSE Leap 15.0"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.0"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

[RamanBut-Husaim]

@janvorli Hello. Sorry for coming back to you with this. Maybe you had time to take a look at this?

openSUSE is one of the most stable linux distros that I've worked with and it is a pity that dotnet does not work with it out of the box.

[janvorli]

@RamanBut-Husaim let me give it a try in a docker container to see what's going on.

[janvorli]

I've tried the 2.1.3 tarball in OpenSUSE Leap docker container and it seems to work fine. Here are the exact steps:

zypper install icu
zypper install libopenssl1_0_0
zypper install wget
zypper install tar
mkdir ~/dotnet
cd ~/dotnet
wget https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.401/dotnet-sdk-latest-linux-x64.tar.gz
tar -xf dotnet-sdk-latest-linux-x64.tar.gz
cd ~
mkdir test
cd test
~/dotnet/dotnet new console
~/dotnet/dotnet run

cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.0"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.0"
PRETTY_NAME="openSUSE Leap 15.0"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.0"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

However, I can confirm that on Tumbleweed it doesn't work - it cannot find the ICU. Looking into it.

[janvorli]

I have found the culprit on Tumbleweed - openSUSE has decided to add suse to the names of the ICU libraries this way:

/usr/lib64/libicuuc.so.suse62.1
/usr/lib64/libicui18n.so.suse62.1
/usr/lib64/libicudata.so.suse62.1

When dotnet core looks for the ICU libraries, it tries various naming conventions used on different systems, but this one is completely unexpected.

As a workaround, you can create the following symlinks, after that, dotnet worked just fine.

ln -s /usr/lib64/libicuuc.so.suse62.1 /usr/lib64/libicuuc.so.62.1
ln -s /usr/lib64/libicui18n.so.suse62.1 /usr/lib64/libicui18n.so.62.1
ln -s /usr/lib64/libicudata.so.suse62.1 /usr/lib64/libicudata.so.62.1

[janvorli]

Note that since Tumbleweed is a rolling distro, the version part of the above mentioned names may change in the future.

[RamanBut-Husaim]

@janvorli Hello, thanks a lot for the update. Thanks, this helps! It could make sense to update the documentation with such approach.

Looking at the lib64 folder in Tumbleweed at the moment. Seems that opensuse has the following symlinks out of the box

libicudata.so
libicui18n.so
libicuuc.so

Not sure that this is the way to go across all other repos but is it possible to use this one instead of version specific?

Thanks.

[janvorli]

@RamanBut-Husaim the non-versioned file comes from a dev package. If you have just the icu runtime package installed, you won't have it. I've created a PR for a fix to add for the case where the version is prefixed by "suse" too.

[leecow]

cc @rakeshsinghranchi, @vivmishra

Another note on this issue as it relates to Leap 15. Our OpenSUSE runtime-deps package is looking for libicu52_1 but libicu60_2 is what's available on the default Leap repos. I'll update the docs to call out the dependency requirement for Leap 15.

[putztzu]

Installing on LEAP is broken again, and I'd expect on TW also based on what has been posted in this Issue. The maintainers of the the install and package should consider using something like the Open Build Service (https://openbuildservice.org/) to build packages so that with a common source packages can be targeted at numerous distros and distro versions. Package builds can be automated so that for instance rolling releases like Tumbleweed are created automatically for each distro release.

[juliusfriedman]

See https://github.com/dotnet/corefx/issues/42194, I can't build from source but the binaries work or so it seems.