Fedora Account System
Red Hat Associate
Red Hat Customer
In the various dotnetX.0 packages (I think dotnet7.0 is still around for F39, and we have 8.0 and 9.0 for F40+), almost all the subpackages are namespaced - so we have dotnet-host-fxr-8.0 and dotnet-host-fxr-9.0, dotnet-sdk-8.0 and dotnet-sdk-9.0, and so on - but the dotnet-host package is not. All three of dotnet7.0, dotnet8.0, and dotnet9.0 produce a subpackage called "dotnet-host". This seems like a problem, because it means the 'current' version of dotnet-host bounces around every time you update one of the packages. For instance, Fedora 40 shipped with dotnet-host-8.0.2-1.fc40 , as you can see in https://dl.fedoraproject.org/pub/fedora/linux/releases/40/Everything/x86_64/os/Packages/d/ . But after the update https://bodhi.fedoraproject.org/updates/FEDORA-2024-3fb74c9518 went stable, the 'current' dotnet-host version for F40 suddenly jumped to dotnet-host-9.0.0~rc.1.24431.7-0.11.fc40 , as you can see in https://dl.fedoraproject.org/pub/fedora/linux/updates/40/Everything/x86_64/Packages/d/ . Worse, if/when https://bodhi.fedoraproject.org/updates/FEDORA-2024-204d982a2e goes stable, the 'current' dotnet-host version will jump back *down* to dotnet-host-8.0.110-1.fc40 - that package will appear in https://dl.fedoraproject.org/pub/fedora/linux/updates/40/Everything , the 9.0 package will no longer be there, and when someone updates their system, the package will be downgraded. This doesn't seem like the way it should be? From the spec file it looks like "in theory" the other components from any dotnet version should be able to work with any version of the host, but still, ping-ponging the 'current' version of dotnet-host around like this seems undesirable. Is there a problem with just namespacing the host package, like all the others? Or, if the paths can't be adjusted to accommodate that, only having one of the source packages build the dotnet-host binary package? Thanks!
Thanks for reporting this! > This doesn't seem like the way it should be? From the spec file it looks like "in theory" the other components from any dotnet version should be able to work with any version of the host, but still, ping-ponging the 'current' version of dotnet-host around like this seems undesirable. Agreed. This is not desirable. I was under the impression that the latest version (so 9.0) would end up in the Everything repo, not the one from the last update. I was not expecting the versions to change. > Is there a problem with just namespacing the host package, like all the others? The dotnet-host package provides /usr/bin/dotnet. Among other things, this handles multiplexing across different versions of .NET. There is no other multiplexer, and no other mechanism for switching between versions. > Or, if the paths can't be adjusted to accommodate that, only having one of the source packages build the dotnet-host binary package? Yeah, this is what we ended up doing for RHEL. I thought things would automagically work better in Fedora, but I guess not. Let me look into doing this on Fedora too.
To be fair...I guess "the latest tagged version will win" is my assumption, I don't know it for 100% sure. That's what happens in a similar case (if you accidentally submit an update with a lower NVR than the previous update, the new-lower-versioned update wins over the older-higher-versioned one), but this isn't exactly the same case. I do *think* that's what happens, but I don't know for 100% sure. On the whole I think it's better to just have one source package build dotnet-host overall, but maybe we could ask FPC or someone for more opinions.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
I implemented this a while ago but forgot to close the issue. https://src.fedoraproject.org/rpms/dotnet8.0/c/da3d2323f56aeb52930530693040dd3caa9c8871?branch=rawhide