Higher version of libicu (6x) installed on OpenSuSE Leap than accepted by dotnet-runtime

[dagood]

@git-gone commented on Sat Mar 23 2019

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install
Operating System: Linux openSUSE Leap

installing as per instructions on page above fail at step to install .net SDK, Added all Microsoft public keys and downloaded repo files as recommended on the web page whose URL appears above

sudo zypper install dotnet-sdk-2.2
[sudo] password for jamest: 
Retrieving repository 'Packman Repository' metadata .................................................................................[done]
Building repository 'Packman Repository' cache ......................................................................................[done]
Loading repository data...
Reading installed packages...
Resolving package dependencies...

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

Choose from above solutions by number or cancel [1/2/c] (c): ^Cjamest@irrelevant:~/Downloads> 

In OpenSuSE, there appears to beno RPM package that provides libicu at version 52. Is it likely that a version of dotnet-runtime will be available for download that will be accept libicu6x in place of libicu52?

Many thanks in advance & best Regards

git-gone

---

@leecow commented on Wed Mar 27 2019

Can you share the output of cat /etc/os-release? Here's what I see on a fresh image ...

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

d2e58356aeaa:/ # zypper search libicu
Loading repository data...
Reading installed packages...

S  | Name               | Summary                                                    | Type
---+--------------------+------------------------------------------------------------+--------
   | libicu-devel       | International Components for Unicode (development files)   | package
   | libicu-devel-32bit | International Components for Unicode (development files)   | package
   | libicu-doc         | International Components for Unicode  (html documentation) | package
i+ | libicu52_1         | International Components for Unicode                       | package
   | libicu52_1-32bit   | International Components for Unicode                       | package
i  | libicu52_1-data    | International Components for Unicode                       | package

---

@SvenjaReissaus commented on Sat Mar 30 2019

I am having the same issue here, there's a higher version of libicu already installed:
$ zypper install libicu

Loading repository data...
Reading installed packages...
'libicu' not found in package names. Trying capabilities.
'libicu60_2' providing 'libicu' is already installed.
Resolving package dependencies...

Nothing to do.

Made a clean install of openSUSE Leap 15.0:
$ 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/"

And the repository search:
$ zypper search libicu

Loading repository data...
Reading installed packages...

S | Name               | Summary                               | Type   
--+--------------------+---------------------------------------+--------
  | libicu-devel       | Development files for the ICU library | package
  | libicu-devel-32bit | Development files for the ICU library | package
  | libicu-doc         | Documentation for the ICU library     | package
i | libicu60_2         | International Components for Unicode  | package
  | libicu60_2-32bit   | International Components for Unicode  | package
  | libicu60_2-bedata  | Rule databases and tables for ICU     | package
i | libicu60_2-ledata  | Rule databases and tables for ICU     | package

---

@karelz commented on Sat Mar 30 2019

@tarekgh @janvorli any thoughts or advice?

---

@SvenjaReissaus commented on Sat Mar 30 2019

Perhaps this workaround from https://github.com/dotnet/core-setup/issues/4413#issuecomment-417505779 is one you could take a look at. I didn't tried it, as I installed ignoring the warning (yet it does not seems to break nor print warnings) but I'll give it a try.

$ dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   2.2.105
 Commit:    7cecb35b92

Runtime Environment:
 OS Name:     opensuse-leap
 OS Version:  15.0
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/2.2.105/

Host (useful for support):
  Version: 2.2.3
  Commit:  6b8ad509b6

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

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

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

---

@tarekgh commented on Sun Mar 31 2019

CC @rakeshsinghranchi

Why we have hard dependency on ICU 52? if the system already have any more recent version of ICU, we should be ok. it looks the package dependency should get fixed.

---

@karelz commented on Sun Mar 31 2019

@tarekgh note that @rakeshsinghranchi's responsibilities in the space were transfered to @dagood

---

@tarekgh commented on Sun Mar 31 2019

thanks @karelz for the info. @dagood may help then here. should this be moved to core-setup?

[dagood]

Why we have hard dependency on ICU 52? if the system already have any more recent version of ICU, we should be ok. it looks the package dependency should get fixed.

Do you have a suggestion on how to do this? The issue I see is that the ICU package name includes the version, e.g. libicu57, libicu52_1. Is there a such thing as "dependency alternative groups" or something like that?

Here's this dependency, FWIW: https://github.com/dotnet/core-setup/blob/19120e4565130fa36d0fa9d5db059c1247c01946/src/pkg/packaging/rpm/dotnet-runtime-deps-rpm_config_opensuse.42-x64.json#L37

From the os-release info above, we might need to handle OpenSUSE 15.0 too, as well as 42? I know something interesting happened with these versions recently, will need to understand that better before taking action.

@leecow thoughts?

should this be moved to core-setup?

Done.

[leecow]

Yes, OpenSUSE "re-engineered" their versioning to align their Leap channel (slow moving stable) with SLES. 15.0 is the next version after 42.3 and we need to support it.

[tarekgh]

@dagood I am seeing 2 issues with ICU dependency:

• if a system installed higher version of ICU and our setup trying to install the lower version 52. I believe this causes our setup to fail because the system already have more recent version than what we require.
• if we are trying to install on distros which doesn't have ICU 52 in their store but could have more recent version.

For the first one, is there a way the setup can handle such case?

For the second one, I think this will depend if we support such distro and if we need to update the dependency on the supported distro. but at least we may want to give option to the users if they can install ICU manually, our setup can succeed at that time.

I now the issue can be more complicated than what I simplify here, I just wanted to share my thoughts to reduce such reports as I am seeing we started to get many of them for same issue. And thanks for your follow up and prompt replies.

[janvorli]

It seems that RPM allows you to specify dependency in way that would work by saying you require ICU >= 50.1. I am no RPM expert, just googled it here: https://rpm.org/user_doc/dependencies.html

[dagood]

It seems that RPM allows you to specify dependency in way that would work by saying you require ICU >= 50.1.

Interesting, I hadn't noticed the icu package rather than the libicu60_2 package. (Note that 60_2 is part of the package name, not a version, and there is no libicu package.) Are you familiar with what icu is adding on top of libicu60_2?

Running the install command tells me icu brings in libicu60_2, which is good, but it also adds 0.6 MiB:

#> zypper install icu
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 4 NEW packages are going to be installed:
  icu libicu60_2 libicu60_2-ledata timezone

4 new packages to install.
Overall download size: 8.4 MiB. Already cached: 0 B. After the operation, additional 32.3 MiB will be used.

#> zypper install libicu60_2
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 3 NEW packages are going to be installed:
  libicu60_2 libicu60_2-ledata timezone

3 new packages to install.
Overall download size: 8.2 MiB. Already cached: 0 B. After the operation, additional 31.7 MiB will be used.

These are the extra files:

#> rpm -ql icu
/usr/bin/derb
/usr/bin/genbrk
/usr/bin/gencfu
/usr/bin/gencnval
/usr/bin/gendict
/usr/bin/genrb
/usr/bin/icuinfo
/usr/bin/makeconv
/usr/bin/pkgdata
/usr/bin/uconv
/usr/sbin/escapesrc
/usr/sbin/genccode
/usr/sbin/gencmn
/usr/sbin/gennorm2
/usr/sbin/gensprep
/usr/sbin/icupkg
/usr/share/doc/packages/icu
/usr/share/doc/packages/icu/license.html
/usr/share/doc/packages/icu/readme.html
/usr/share/icu
/usr/share/icu/60.2
/usr/share/icu/60.2/LICENSE
/usr/share/man/man1/derb.1.gz
/usr/share/man/man1/genbrk.1.gz
/usr/share/man/man1/gencfu.1.gz
/usr/share/man/man1/gencnval.1.gz
/usr/share/man/man1/gendict.1.gz
/usr/share/man/man1/genrb.1.gz
/usr/share/man/man1/icu-config.1.gz
/usr/share/man/man1/makeconv.1.gz
/usr/share/man/man1/pkgdata.1.gz
/usr/share/man/man1/uconv.1.gz
/usr/share/man/man8/genccode.8.gz
/usr/share/man/man8/gencmn.8.gz
/usr/share/man/man8/gensprep.8.gz
/usr/share/man/man8/icupkg.8.gz

If this is fine, then we should certainly depend on icu for the openSUSE runtime-deps package for forward compatibility.

[dagood]

I realized I can look at the advertised package info:

#> zypper info icu

• Installed Size : 630.3 KiB
• Description:
  • ICU is a set of C and C++ libraries that provide extensive Unicode and locale support, such as calendar, conversions for many character sets, language sensitive collation, date and time formatting, support for many locales, message catalogs and resources, message formatting, normalization, number and currency formatting, time zone support, transliteration, and word, line, and sentence breaking.
    This subpackage contains the runtime programs for interacting with ICU.

#> zypper info libicu60_2

• Installed Size : 4.8 MiB
• Description :
  • ICU is a set of C and C++ libraries that provide extensive Unicode locale support.
    This package contains the runtime libraries for ICU.

---

@leecow, is it worth including the 630.3 KiB of icu programs we know we don't need to have a more stable dependency across openSUSE versions?

Is openSUSE commonly used to host microservices, or other situations the extra size has particular impact?

For comparison, we are in a similar situation with our Debian and Ubuntu libicu52/libicu57/... packages. They also have a package that doesn't have a version in its name called icu-devtools, which appears to have the same purpose as openSUSE's icu and is around the same size. Should/can we do the same for these distros?

I view this change as a workaround for some distros that only make libicu available with versions in its name. Changing to icu mitigates the maintenance cost but makes one of our dependencies wrong. From my point of view the situation isn't rough enough to justify it.

(Linking ICU statically would be another way around this, but that's not going to happen: https://github.com/dotnet/coreclr/issues/5853.)

[tarekgh]

Side point, in the near future we may need to have something like preferred ICU version in addition to min ICU version. I mean if the setup can install the preferred version or later that will be great. otherwise the setup want to ensure at least the min version is available.

I am telling that because in May 1, 2019 Japan is going to have a new era in their calendar. The new era will be supported by the new ICU version which would be the preferred version for us. if we don't have this mechanism in the setup, we'll have to advise people to manually upgrade the ICU on their machines which is not a good experience to users.

[tarekgh]

Or we can have the setup always target the greatest ICU version available for the distro.

[janvorli]

in the near future we may need to have something like preferred ICU version

In most major distros, the major.minor ICU version is tied to the distro version. There are only a few distros with rolling versions of packages.

[tarekgh]

In most major distros, the major.minor ICU version is tied to the distro version. There are only a few distros with rolling versions of packages.

Maybe you know better here but I am wondering such distros don't allow installing higher versions if it is available?

like doing something

zypper install libicu60_2

and if it fail we'll just fallback to whatever version we have today. my point is try to install the higher version and then fallback if we couldn't.

[janvorli]

The thing is that they never make a newer version available for a specific version of the distro. So for example, Ubuntu 14.04 carries libicu52, Ubuntu 16.04 libicu55 etc. They were released with those versions and stick with it.
Of course there are ways to install newer libicu - e.g. from a binary tarball provided on the ICU site, building it from sources or installing from an unofficial source. But we cannot expect people in general to do that.

[dagood]

I noticed this line in our setup instructions:

sudo zypper install libicu

It turns out that even though the package is named libicu60_2, it "provides" libicu capability, so that command works:

#> zypper install libicu
Loading repository data...
Reading installed packages...
'libicu' not found in package names. Trying capabilities.
Resolving package dependencies...

The following 3 NEW packages are going to be installed:
  libicu60_2 libicu60_2-ledata timezone

I tried it out, and we can actually depend on libicu in the runtime-deps package and it works!

#> zypper install dotnet-runtime-deps-3.0.0-preview4-27522-0-opensuse.42-x64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 5 NEW packages are going to be installed:
  dotnet-runtime-deps-3.0 libicu60_2 libicu60_2-ledata libopenssl1_0_0 timezone

(This might be unique to openSUSE or some family of distros. For Debian 9, at least, apt-get install libicu gives up with E: Unable to locate package libicu.)

So, for this issue, we should change the openSUSE 42.0 runtime-deps package dependency from libicu60_2 to libicu. Then it can work with whatever package the distro has that provides the libicu capability.

[janvorli]

This might be unique to openSUSE or some family of distros

Maybe it is specific to distros using RPM packages (just guessing).

[leecow]

Agreed with trying to update the dependency to just 'libicu'. If you could hack an rpm and a deb together, I can do a local test easily enough.

[leecow]

@omajid to chime in on the premise.

[omajid]

I looked through the RPM based distros (RHEL 7, 8, Fedora 29, 30 OpenSUSE Leap 15 and Tumbleweed). All of these have a real package or package providing libicu (with different versions, of course) that you can depend on from your package. I don't see any issues depending on a virtual Provides vs real package.

Debian and friends don't seem to have anything equivalent that I could see. But I am not familiar with debian, so I may just have missed something.

[dagood]

Closing, this was done a while ago, and it's in 2.1.12.

I haven't had a chance myself to do a fuller validation of the results, but there haven't been any reports of problems, and if any turn up, I'd expect the best way to handle them is by filing new issues.

[Mailaender]

I still get the error message that dotnet wants to downgrade libicu on @openSUSE 15.1:

Problem: krb5-libs benötigt von dotnet-runtime-deps-3.1-3.1.1-1.x86_64 wird nirgends zur Verfügung gestellt
 Lösung 1: Folgende Aktionen werden ausgeführt:
  dotnet-runtime-3.1-3.1.1-1.x86_64 nicht installieren
  aspnetcore-runtime-3.1-3.1.1-1.x86_64 nicht installieren
  dotnet-sdk-3.1-3.1.101-1.x86_64 nicht installieren
 Lösung 2: Downgrade von libicu60_2-60.2-lp151.3.3.1.x86_64 zu libicu60_2-60.2-lp151.2.4.x86_64

You may not notice that on a fresh VM install, but if you run updates it will break.

[dagood]

That error's a little weirder than that, it seems to me. Machine translating gives me:

Problem: krb5-libs required by dotnet-runtime-deps-3.1-3.1.1-1.x86_64 is nowhere available
  Solution 1: The following actions are carried out:
   Do not install dotnet-runtime-3.1-3.1.1-1.x86_64
   Do not install aspnetcore-runtime-3.1-3.1.1-1.x86_64
   Do not install dotnet-sdk-3.1-3.1.101-1.x86_64
  Solution 2: downgrade from libicu60_2-60.2-lp151.3.3.1.x86_64 to libicu60_2-60.2-lp151.2.4.x86_64

Why is krb5-libs not existing going to be resolved by downgrading libicu? What does this have to do with .NET Core?

@Mailaender can you please file a new issue in dotnet/runtime? I can take a look later.

[Mailaender]

It could have something to do with https://build.opensuse.org/request/show/764336. The easiest solution might be to

	Requires: icu

which itself depends on the correct version of libicutu.so.60.2()(64bit) so you won't need to update this all the time. Downside may be that depend on runtime programs you don't need and the API might become incompatible.

[dagood]

I noticed that earlier at https://github.com/dotnet/core-setup/issues/5628#issuecomment-478702149 --yeah, reluctant because it brings in stuff we don't use. We'll probably have to start building (more) version-specific packages.