Add installation instructions for Fedora 32

[omajid]

This is based off the existing instructions for Fedora 31, with a few changes:

• .NET Core (3.1) packages are part of the default package repositories in Fedora 32. No extra repositories need to be enabled to be able to install .NET Core 3.1.

• Only 3.1 is available in the Fedora package repositories. So I added a comment suggesting users to install other SDK/Runtime versions manually. The other versions need to be a manual install because mixing dotnet packages from package repositories is a bad idea. For example, it might pull down sdk bits built by Microsoft but everything else built by Fedora. And that doesn't work: cannot run "dotnet new console" core#4605

• The package manager troubleshooting comments are all specific to the Microsoft repository. So I didn't add them here.

Fixes: #18038

[kqr]

Unless I'm misreading things, the last link to instructions for manually installing older runtimes is broken – it seems to be missing the "install" directory in the path it references.

[omajid]

@kqr Hey, is there some way I can view the final render? You are probably right and I want to make sure I dont screw up other links similarly.

[kqr]

"Files changed" tab, then the three dots context menu, and then "View file".

[kqr]

On this subject, have you tried following those instructions after installing .NET Core 3.1 through the repositories? It looks like those instructions recommend clobbering the $DOTNET_ROOT variable, which will render the 3.1 installation unusable.

(I instead installed older runtimes into the existing $DOTNET_ROOT (created by the official Fedora packages for 3.1), making sure to not overwrite anything but what's in host and shared directories, and that seems to have worked to have both runtime versions installed side by side.)

[kqr]

All of this to say that we might benefit from specific instructions for installing older versions side-by-side with the newer SDK for Fedora 32, where one does not extract blindly into $DOTNET_ROOT, but instead first extracts to a separate directory and then rsyncs just host and shared from that to $DOTNET_ROOT.

I might take a stab at writing this up more formally if I can find the time, and only once I've been able to more thoroughly test that my method actually has worked.

[omajid]

On this subject, have you tried following those instructions after installing .NET Core 3.1 through the repositories?

No, but ...

It looks like those instructions recommend clobbering the $DOTNET_ROOT variable, which will render the 3.1 installation unusable.

I think mixing contents installed by the package-manager and from a manual install might not be a great idea. It definitely violates FHS which would suggest putting those pieces in /usr/local or some place. Operations from package mangers might be incomplete (or might delete more than necessary) if there are contents from different sources left on disk. Also, can you imaging getting a bug report about this and trying to sort out what the source of the bits is and where the problem originates?

[Thraka]

@omajid Thanks for adding this! Can you please update the other following files with links to this article?

• docs\core\install\includes\package-manager-switcher.md (around line 10)
• docs\core\toc.yml (around line 39)

[Thraka]

This should be removed. These are instructions on installing over versions of .NET on this distro through the package manager, which you indicate doesn't work. So we don't need this include 😄

Suggested change

	## How to install other versions
	[!INCLUDE [package-manager-switcher](./includes/package-manager-heading-hack-pkgname.md)]
	If a package is not available you should [manually install the .NET Core SDK](sdk.md?pivots=os-linux#download-and-manually-install) or [manually install the .NET Core Runtime](runtime.md?pivots=os-linux#download-and-manually-install).
	## How to install other versions
	To install other versions of .NET Core, manually install [.NET Core SDK](sdk.md?pivots=os-linux#download-and-manually-install) or [.NET Core Runtime](runtime.md?pivots=os-linux#download-and-manually-install).

[omajid]

Thanks for the review, @Thraka. I think I have fixed everything you asked for. Can you please take another look?

[kqr]

I think mixing contents installed by the package-manager and from a manual install might not be a great idea. It definitely violates FHS which would suggest putting those pieces in /usr/local or some place. Operations from package mangers might be incomplete (or might delete more than necessary) if there are contents from different sources left on disk. Also, can you imaging getting a bug report about this and trying to sort out what the source of the bits is and where the problem originates?

I agree it's a bad idea, but it might be a necessary evil in some cases. I work in a professional capacity with both 2.1 and 3.1 projects. I only need to 3.1 SDK, of course, but in order to run the 2.1 projects I also need a 2.1 runtime, which isn't available from Fedora 32 repositories.

I could try installing the 3.1 SDK and runtime from the Fedora repositories, and the 2.1 runtime from the Microsoft repositories (as well as everything from the Microsoft repositories), but I didn't quite get this to work (probably due to different assumptions on $DOTNET_ROOT.) So what did work, finally, was installing the 3.1 SDK and runtime from Fedora repositories, and manually extracting the relevant parts of the 2.1 runtime into $DOTNET_ROOT.

[Thraka]

Thanks again for making this content.

[Thraka]

@omajid Question on this, do you need to ever do sudo dnf update ?

[omajid]

Only to update the packages you have installed on your disk, I think.

Unlike apt where apt-get update fetches information about the latest versions of packages so apt-get install and apt-get upgrade can work with it, dnf does it automatically.

If you do a new Fedora installation (nothing in the package cache) or run a Fedora VM after a few days of not using it (the package cache is too old), dnf install dotnet-sdk-3.1 will automatically fetch the information about the latest versions of packages when invoked.

dnf update is an alias for dnf upgrade. Both upgrade all installed packages to their latest version. The dnf version of apt-get update is dnf check-update, but I don't think I have ever used it.