Runtime: Use OR ('|') dependencies for Debian packages for libicu## dependencies

[dagood]

Debian packages support | to declare a dependency that may be met by any of a set of packages:

In the Depends, Recommends, Suggests, Pre-Depends, Build-Depends, Build-Depends-Indep and Build-Depends-Arch control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols |. In such a case, that part of the dependency can be satisfied by any one of the alternative packages.
[...]

Package: mutt
Version: 1.3.17-1
Depends: libc6 (>= 2.2.1), default-mta | mail-transport-agent

(https://www.debian.org/doc/debian-policy/ch-relationships.html)

We should do this for libicu60 | libicu57 | libicu55 | libicu52 ... in dotnet-runtime-deps. This lets us provide one runtime deps package across all releases of a distro.

The reason we should make a package that works across all releases is it's increasingly common for users to have the wrong Microsoft package repository set up, causing "dependencies unmet" errors that they (understandably) turn to us for help with. Making the repositories for each release carry the same dotnet-runtime-deps package allows any feed they may have installed to work.

I think we should include plain libicu in the | list, in case some specific distro happens to be awesome and include/start including Provides: libicu in their libicu## package.

/cc @leecow

---

This is effectively the Debian package side of https://github.com/dotnet/core-setup/issues/5628. On RPM-using distros, their libicu## packages "provide" libicu, so we can simply depend on libicu. Unfortunately that isn't the case for Debian distros I've checked out--we have to list out every concrete version. But the principle and end result is the same.

[dagood]

I have a branch for this, and it works fine, but I'm wondering if we should actually go ahead and apply this to the Deb package for libssl1.0.0 | libssl1.0.2 | libssl1.1 as well. If we did, I believe we'd end up with a single runtime-deps package that works everywhere. If we don't, we aren't actually gaining all that much with this change because libssl versions still require us to maintain a deps package per distro and sometimes per distro release.

RPM has or, too: https://rpm.org/user_doc/boolean_dependencies.html. It looks like we could similarly collapse those.

@omajid do you think this would work, for the RPM packages at least? I imagine any concerns would apply to Deb as well.

/cc @dleeapho @leecow

[dleeapho]

I'm in favour of applying it for libssl dependencies as well. Having a single runtime-deps that works everywhere is goodness.
/cc @MichaelSimons

[dagood]

It looks like or is a "new" (Nov 2016) feature in RPM, and we can't use it everywhere yet:

Starting with rpm-4.13

In our current build image and most distros we support (that I have Docker images for), rpm is 4.11.3 or lower. The only place I noticed 4.13+ is opensuse/leap:15.0, with 4.14.1. Doesn't seem worth doing.

I'll just do it for Debian packages for now.

[Ghostbird]

I'd like to see the dependencies libicu57 and libssl1.0.2 amended.
I can no longer install .NET Core on Debian 10.
If this would not cause any big problems I'd recommend allowing libicu63 and libssl1.1 which _are_ available on Debian 10.
Debian 10 has been feature frozen, and only critical bugs are fixed before it is released. This would be a great time to get .NET Core packaging ready for Debian 10, and have a working .NET Core source line available (e.g. deb [arch=amd64] https://packages.microsoft.com/debian/10/prod buster main) when Debian 10 is released.

[dagood]

libicu63 and libssl1.1 are already set to be included with this work, so we're good to go as far as Core-Setup is concerned:

https://github.com/dotnet/core-setup/blob/ccea2e606d948094cf861b81e15245833bfb7006/src/pkg/packaging/deb/package.targets#L343-L354

Debian packages with these improved dependency lists should be available in the next .NET Core 2.1/2.2 servicing release, which is currently planned for July (unless things change).

@leecow may know more about standing up a Debian 10 feed. However, in theory we don't need a new feed once we have the | dependencies. We may want a new all-distro feed.

[Ghostbird]

@leecow may know more about standing up a Debian 10 feed. However, in theory we don't need a new feed once we have the | dependencies. We may want a new all-distro feed.

Thanks for the info. I manually downloaded the 2.2.5 deb package from the index and modified its control file to allow installation with libssl1.1 and libicu63. So far I have encountered no problems, but if something Debian 10 specific pops up, I'll report it.

[dagood]

I confirmed that the 2.1.12/2.2.6 release includes this change, and works across various distros/releases. For example, I can go as far as using the Ubuntu 19.04 instructions to install in a Debian 10 Docker container.