This blocks from having multiple versions of dotnet coexisting. An simple fix would be having IUSE="dotnet-symlink" in virtual/dotnet-sdk itself. Tho a better solution would be a eselect module for dotnet-sdk, and having away with the symlink useflag at all.
> This blocks from having multiple versions of dotnet coexisting. It does not, it will block multiple virtuals only (because they require dotnet-symlink), the way to get multiple dotnet versions is to have only one use dotnet-symlink. See: > (~)λ dotnet-bin-7.0 --list-runtimes > Microsoft.AspNetCore.App 7.0.0 [/opt/dotnet-sdk-bin-7.0/shared/Microsoft.AspNetCore.App] > Microsoft.NETCore.App 7.0.0 [/opt/dotnet-sdk-bin-7.0/shared/Microsoft.NETCore.App] > (~)λ dotnet-bin-6.0 --list-runtimes > Microsoft.AspNetCore.App 6.0.10 [/opt/dotnet-sdk-bin-6.0/shared/Microsoft.AspNetCore.App] >Microsoft.NETCore.App 6.0.10 [/opt/dotnet-sdk-bin-6.0/shared/Microsoft.NETCore.App] I agree this is quite "meh" but this is the work of the previous maintainer (i think I have not changed it much...?) Yes I agree we should drop symlink stuff and have a proper eselect and eclass. Since "dotnet-bin-7.0" is able to pick up proper sdk/runtime (THX MS!) the eclass can determine the SDK to use using a simple loop check > for _dotnet in dotnet-bin-7.0 dotnet-bin-7.0 ; do > if type $_dotnet ; then > DOTNET_FOR_BUILD=$_dotnet > break > fi > done Instead of calling "dotnet" (which then would actually be a symlink) and probably failing miserably.
Created attachment 836583 [details] eselect module prototype I made a basic prototype for it, based this on the lua eselect module, it's probably not the best since it's my first module tho.
Are there plans to fix "dotnet --list-sdks" so it actually would list ALL installed sdks or it is out opf scope of this issue?
(In reply to Marat Radchenko from comment #3) > Are there plans to fix "dotnet --list-sdks" so it actually would list ALL > installed sdks or it is out opf scope of this issue? "dotnet --list-sdks" does not work on Gentoo currently and will not work with the new approach. And by that I mean that it can list only the SDKs that the currently used (current approach) or eselected (new) "dotnet" exe detects. Afaik list-sdks can only detect SDKs from the given "dotnet" exe prefix. I do not think we can throw all of .NET SDKs to one directory. Maybe an approach would be to just copy the right SDK dirs into one /opt/dotnet? which "dotnet" executable would we use then? I think "dotnet --list-sdks" was designed for people who run a dotnet install under their user. For system "listing" we could use eselect (new approach) which could be able to detect SDK dirs. > 7.0.201 [/opt/dotnet-sdk-bin-7.0/sdk] but would we need that? Yes, the new approach will differ slightly from what somebody might be used to with their .NET development but imho it will be more usable than current one.
https://github.com/gentoo/gentoo/pull/32109 merged.
