Bug 926615 – dotnet-pkg-base.eclass: unrequired virtual/dotnet-sdk:${DOTNET_PKG_COMPAT} is getting installed

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Anton Bolshakov 2024-03-09 23:38:32 UTC]

Hi,

I wrote my own ebuild which requires DOTNET_PKG_COMPAT=6.0 .
However, during installation, virtual/dotnet-sdk-8.0 is getting installed as well.

Here is the output:

[ebuild  N     ] dev-dotnet/dotnet-runtime-nugets-7.0.15:7.0.15::gentoo  292,461 KiB
[ebuild  N     ] dev-dotnet/dotnet-runtime-nugets-8.0.1-r1:8.0.1::gentoo  313,331 KiB
[ebuild  N     ] dev-dotnet/dotnet-runtime-nugets-6.0.26:6.0.26::gentoo  288,182 KiB
[ebuild  N     ] dev-dotnet/dotnet-runtime-nugets-6.0.25:6.0.25::gentoo  288,168 KiB
[ebuild  N     ] app-eselect/eselect-dotnet-1.0.1::gentoo  9 KiB
[ebuild  N     ] dev-libs/userspace-rcu-0.14.0:0/8::gentoo  USE="-static-libs -test" 646 KiB
[ebuild  N     ] dev-util/lttng-ust-2.12.1:0/2.12::gentoo  USE="-examples -numa" 840 KiB
[ebuild  N     ] dev-dotnet/dotnet-sdk-bin-8.0.101-r3:8.0/8.0.1::gentoo  209,202 KiB
[ebuild  N     ] dev-dotnet/dotnet-sdk-bin-6.0.417-r4:6.0/6.0.25::gentoo  181,886 KiB
[ebuild  N     ] virtual/dotnet-sdk-8.0:8.0::gentoo  0 KiB
[ebuild  N     ] virtual/dotnet-sdk-6.0-r2:6.0::gentoo  0 KiB
[ebuild  N     ] dev-dotnet/csharp-gentoodotnetinfo-1.1.1-r1::gentoo  USE="-debug" 692 KiB
[ebuild  N     ] app-misc/gedkeeper-3.5.1::localrepo  USE="-debug" 257,227 KiB


I suppose that it shouldn't. Could you have a look and fix eclass/dotnet-pkg-base.eclass?

Thank you.

[Comment 1 Alfred Wingate 2024-03-10 00:08:00 UTC]

In your output dev-dotnet/csharp-gentoodotnetinfo would be pulling in dotnet-sdk-8.0. The eclass requires this dependency for querying .NET information.

In future it would be useful to include the ebuild as well if it wasnt clear where the unwanted the dependency is coming from.

[Comment 2 Maciej Barć 2024-03-10 00:23:48 UTC]

Anton,
this is intended behavior, each pkg using .NET locks onto a specific .NET SDK major version.

This is to:
- ensure we always build on the same SDK that we tested on, imagine if we tested on 8.0 but some user built on 7.0, in case of .NET this can cause unexpected breakages,
- have less NUGET "dependencies",
- have simpler and more strict dependency chain.

If you want to reduce number of dependncies you can try and port the package you require to new SDK version. In most cases it is just a change to the TargetFramework tag.