Debian 11 - allow installation against libicu67

[nzbart]

I see that there is a list of known libicu versions, aptly named KnownLibIcuVersion. Is it possible to add libicu67 to the list so that dotnet can be installed on Debian Testing?

Currently, this is the error I get when trying to install:

apt-get install -y dotnet-sdk-2.1 dotnet-sdk-3.1 azure-cli code
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 dotnet-runtime-deps-2.1 : Depends: libicu but it is not installable or
                                    libicu66 but it is not installable or
                                    libicu65 but it is not installable or
                                    libicu63 but it is not installable or
                                    libicu60 but it is not installable or
                                    libicu57 but it is not installable or
                                    libicu55 but it is not installable or
                                    libicu52 but it is not installable
 dotnet-runtime-deps-3.1 : Depends: libicu but it is not installable or
                                    libicu66 but it is not installable or
                                    libicu65 but it is not installable or
                                    libicu63 but it is not installable or
                                    libicu60 but it is not installable or
                                    libicu57 but it is not installable or
                                    libicu55 but it is not installable or
                                    libicu52 but it is not installable
E: Unable to correct problems, you have held broken packages.

This Dockerfile reproduces the issue:

FROM debian:testing-20200908
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get install -y wget
RUN wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
RUN dpkg -i packages-microsoft-prod.deb
RUN apt-get update; \
  apt-get install -y apt-transport-https && \
  apt-get update && \
  apt-get install -y dotnet-sdk-3.1

Build with:

sudo docker build -t dotnetinstall .

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern, @krwq
See info in area-owners.md if you want to be subscribed.

[safern]

@tarekgh @ericstj I guess we would need to backport this to 2.x, 3.x and 5.0?

[tarekgh]

Is there a way to avoid listing the version numbers in the dependencies? I am guessing we'll need to do that again with new ICu versions?

[tarekgh]

by the way, I am still seeing this infrastructure issue more than globalization :-)

[tarekgh]

@safern is this the same issue https://github.com/dotnet/core/issues/5019?

[tarekgh]

@nzbart what version of Debian you have?

[nzbart]

@tarekgh For day-to-day development, I run Debian Testing (what will be Debian 11) so that I have the most recent versions of the O/S and software. I deploy to Debian 10 stable.

[tarekgh]

it looks according the doc https://docs.microsoft.com/en-us/dotnet/core/install/linux-debian we are not supporting Debian 11 yet.

CC @dagood

[nzbart]

@tarekgh I realise that official Debian 11 support will only come several months after official release of Debian 11. Due to the infrequent (around once every two years) release cycle of Debian stable versions, it'd be great if it was still possible to install and run on the latest version - maybe via a beta channel or similar? Not many developers will be running the stable version of Debian other than for production deployment.

As it currently stands, it's looking like this issue will prevent the installation via apt-get of the dotnet tooling for Debian based distros (except Ubuntu) until some time near the end of 2021 or beginning of 2022. The current situation is that we either need to manually download and install the binaries (and remember to manually update them) or use the snap version, which appears to be poorly supported by tooling such as Rider and VS Code.

[tarekgh]

@nzbart I am not objecting to do something here. I support unblocking Debian 11 usage.

@dagood @safern could you advise what need to be done here? I marked this issue as release blocking but please advise if this is not the case.

[dagood]

This is an area-Setup issue since it's specifically about the Debian package dependencies. (If there were a problem at runtime when libicu67 is installed, then I suppose it'd be area-System.Globalization.)

For context, the linux-x64 .tar.gz extract/use workflow works right now on Debian 11: dotnet/source-build#782 (comment).

---

The way it normally works is that libicu67 will get in the list at some point before Debian 11 is released, or on the .NET servicing release after Debian 11 is released. IMO it's fine to get it in early. This dependency is part of an "or" list, so it doesn't negatively impact other distros/versions.

Keep in mind that it'll only take effect on the next servicing release after merging a PR, because we only build/release new runtime-deps packages as part of a servicing release. (I think that we should decouple runtime-deps from servicing releases and opened this proposal earlier this year: #35672.)

I'm not in area-Setup anymore BTW 😄 /cc @dleeapho @NikolaMilosavljevic @leecow

[dagood]

Is there a way to avoid listing the version numbers in the dependencies? I am guessing we'll need to do that again with new ICu versions?

A few ways:

• Get .NET into Debian proper. 🚀 .NET Core in Linux Distro Repositories source-build#782
• Convince Debian to start naming this package libicu (or provide both names) so we can get off this libicuXX treadmill.
• Build a separate dotnet-runtime-deps for every version of Debian (and Ubuntu, etc.). But this just makes everything more complex and there are even more lists.

[jmp75]

Convince Debian to start naming this package libicu (or provide both names) so we can get off this libicuXX treadmill.

This sounds a very reasonable request to the debian package manager. In my very shallow understanding of package design if libicu versions are backward compatible having a libicu package pointing to "the latest" is a good thing.

dotnet/source-build#782 would be fantastic. Am not qualified to do it but would be glad to contribute/test.

[dagood]

This sounds a very reasonable request to the debian package manager. In my very shallow understanding of package design if libicu versions are backward compatible having a libicu package pointing to "the latest" is a good thing.

Come to think about it, as far as I know, nobody's ever directly asked. 😄 If that happens, our packages will automatically start working right away because we already include libicu as an option.

[safern]

It seems like this is a little more convoluted, so I removed my assignment in the meantime to wait for the area-Setup owners to chime in. Thanks, @tarekgh and @dagood

[NikolaMilosavljevic]

@NikolaMilosavljevic , please explore asking Debian package maintainer to add unversioned libicu package to point at latest included in distro.

Otherwise wait on Debian 11 release to add support in deps packages.

[NikolaMilosavljevic]

Fixed with linked PR.

[dagood]

Any luck on the forward-thinking part?

@NikolaMilosavljevic , please explore asking Debian package maintainer to add unversioned libicu package to point at latest included in distro.

[NikolaMilosavljevic]

Any luck on the forward-thinking part?

@NikolaMilosavljevic , please explore asking Debian package maintainer to add unversioned libicu package to point at latest included in distro.

We are tracking that task with #43419