Incorrect baseurl path in yum repository when installing repo on CentOS 8.x

[slamj1]

Issue Title

When installing the Microsoft yum repository on CentOS 8.x from https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm, the baseurl in /etc/yum.repos.d/microsoft-prod.repo contains an incorrect path.

General

Version Info:
CentOS 8.1.1911 Minimal install with latest patches.
.NET SDK 3.1.105-2.el8_2 (Latest at the time of writing)

To Reproduce:

dnf install https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
dnf makecache (or any other attempt to use the repository)

An error will occur indicating dnf is unable to find the repository.

Temporary Fix:

edit the file /etc/yum.repos.d/microsoft-prod.repo :

Change the line:
baseurl=https://packages.microsoft.com/rhel/8.0/prod
To:
baseurl=https://packages.microsoft.com/rhel/8/prod

Cheers.

[dagood]

CentOS 8.x from https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm

Why are you trying this? There are no .NET Core packages on that feed (browsing https://packages.microsoft.com/rhel/8/prod/ gives you an accurate picture), and the CentOS 8 instructions indicate that .NET Core is available on CentOS 8 without any extra repositories.

We (.NET Core folks) don't own these package repositories, so we can suggest a fix to the owning team, but if it's just for the sake of correctness I somewhat doubt they'll take action on it based on our input. If there is a reason this should work, in the short term we would probably put instructions on the page to work around the problem, and then track it with them for a fix in the long term. (See dotnet/docs#17537 (comment) for another example of a bug in a similar setup package.)

[slamj1]

I originally wrote an internal procedures doc based on the install instructions for CentOS 7. At that time there wasn't instructions for CentOS 8 with respect to SDK install yet. I'm pretty sure (not 100% though), that the https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm was available, which is why I took that route. Once the repo path is corrected this repository does work.

However, now that I see the SDK is part of the base CentOS 8 repositories, that is certainly the one that should be used.
I know things change rapidly and I should have rechecked the install docs for any updates related to CentOS 8.

Up to the team if they want to put this issue forth to the owning team.

Thanks.

[dagood]

Once the repo path is corrected this repository does work.

I'm pretty close to certain what you're experiencing is that when you fix up the path and dnf commands stop emitting errors, you're actually getting the SDK from the default repositories. (Adding the rhel 8 Microsoft repo ending up as a big no-op.)

I'll leave it up to @NikolaMilosavljevic and @adegeo if we should follow up with the repo admins, or see if there's something we can do in the docs to maybe shine a light on the idea that repo paths will not necessarily work predictably if you replace one version number with another.

[slamj1]

I'm pretty close to certain what you're experiencing is that when you fix up the path and dnf commands stop emitting errors, you're actually getting the SDK from the default repositories.

Yes, that's likely what's happening now. Out of curiosity, do you know when .NET core repositories for CentOS 8 were added to the base?

[omajid]

Out of curiosity, do you know when .NET core repositories for CentOS 8 were added to the base?

.NET Core was actually added to RHEL 8. And CentOS 8 picked it up from RHEL 8, similar to how CentOS picks up OpenJDK, Python, GCC, etc from RHEL.

IIRC .NET Core 2.1 should have a part of CentOS 8's initial release. .NET Core 3.1 would have been added some time during the CentOS 8.1 timeframe.

[slamj1]

Thanks for the info, @omajid

[adegeo]

I don't think it's useful to put in a note in the docs telling people not to do this when the latest instructions state that it's automatically available and just run X command to get it. Unless of course we get tons of people trying to do this 😉

[dagood]

I guess the more general "issue" is that manually putting together a URL actually does work a lot of the time, and advanced Linux users might expect it to, based on how other repositories operate. (Perhaps ones that are more single-product or single-org focused.) For example, people were trying to use an Ubuntu 20.04 URL long before we had packages on the feed, and that got very noisy.

As more distros get .NET Core in their default repositories like CentOS 8 has, we may see more reports along similar lines. (As well as more direct conflicts between the distro build and Microsoft build, separate issue dotnet/docs#18347.) OTOH, as long as the feed setup package doesn't have a bug like the one we discussed here, the switchover should be mostly invisible (or hit dotnet/docs#18347).

When people hit an issue with a version twiddling approach, they've probably been away from the docs for a while--so yeah, any doc we add would just be some note they would have to remember for potentially years to make any use of. 😕 Agreed there's probably no useful action we can take on that side.

So how can someone get pointed to the .NET Core install docs when a Linux package manager based install breaks? Pointing people to the docs in issues like this one increases the chances that someone in the future finds these threads through searches and follows it to the docs... so I guess we're actually chipping away at the problem as we speak. 🙂