dotnet sdk installed incorrectly

[Michael]

dotnet binary installed to
/usr/lib/dotnet/dotnet
link in /usr/bin is incorrect:
/usr/bin/dotnet -> ../lib/dotnet/dotnet
should be
/usr/bin/dotnet -> /usr/lib/dotnet/dotnet

incorrect link causes failure with dotnet fake build. System is unable to find assemblies.

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

dotnet6:
  Installed: 6.0.121-0ubuntu1~22.04.1
  Candidate: 6.0.121-0ubuntu1~22.04.1
  Version table:
 *** 6.0.121-0ubuntu1~22.04.1 500
        500 http://us.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages
        100 /var/lib/dpkg/status

I expected
$ dotnet fake build
to build the project

What happened
$ dotnet fake build
was unable to find assemblies

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: dotnet6 6.0.121-0ubuntu1~22.04.1
ProcVersionSignature: Ubuntu 6.2.0-26.26~22.04.1-generic 6.2.13
Uname: Linux 6.2.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: i3
Date: Thu Aug 17 14:11:08 2023
InstallationDate: Installed on 2023-04-19 (120 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
SourcePackage: dotnet6
UpgradeStatus: No upgrade log present (probably fresh install)

[Mateus Rodrigues de Morais (mateus-morais)]

Hello Michael, thank you for reporting this bug!

The link /usr/bin/dotnet -> ../lib/dotnet/dotnet is a valid one per Debian Policy [1], which states that "In general, symbolic links within a top-level directory should be relative, and symbolic links pointing from one top-level directory to or into another should be absolute."

In fact, the "decision" to make the link relative is automatically made by a tool called dh_link [2], which creates these links conforming with Debian Policy.

It seems that FAKE's SDK Resolver isn't handling this well and fails to find assemblies. Therefore, we believe that this is an issue that should be resolved on FAKE's side.

[1] https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links
[2] https://manpages.debian.org/testing/debhelper/dh_link.1.en.html#DESCRIPTION