-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microsoft and source-built Linux packages don't mix well #47500
Comments
It seems like |
I ran into this just now myself. I needed to run a powershell script so I installed powershell using instructions from: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7.1#fedora. Now I get a mix of packages, and installation fails:
Can we move this issue to source-build repo? cc @dagood |
Yum repository files have a The default repo priority is 99, and if a repo increases the value of the Here's a test on Fedora 33:
If we can insert this option directly in the repo file, that might be good enough. We can do this by adding this line directly in the repo file: |
The proposed |
Oh wow, when I saw priority mentioned in one of these issues earlier (I've been collecting the ones I see in dotnet/docs#18347), based on the name, I thought it would only affect what happens when the same package with the same version is available in two repos. I'm surprised that it actually prevents upgrade even when a newer version is available on the less prioritized feed. It certainly makes sense that it works this way though, or it would be a pretty weak feature. 😛 Yeah, to give a little extra context why it doesn't help with 5.0: the mix of packages with major.minor in the name ( (On the other side, if you want to get .NET from packages.microsoft.com, it seems that prioritizing packages.microsoft.com would work, because it's always a superset as far as .NET packages are concerned.) If we could have fake temporary
This means to me that we have to have packages.microsoft.com themselves actually put the deprioritization in the central repo config files, because the powershell instructions (and more?) just download and install that packages.microsoft.com repo file.
It certainly affects the use of distros with source-built SDKs. (/cc @dseefeld @crummel.) But I'm not sure what we can do about this on the source-build side--dotnet/runtime area-Setup is about the Microsoft packaging side of things, so I think it's correct to be here. |
For .NET 5.0, at least, I think it would be faster to just review and build the real packages. They are ready from my side and I am waiting for a formal review: https://bugzilla.redhat.com/show_bug.cgi?id=1919037 |
It looks like this problem also shows up for feature bands that Fedora doesn't build--I suppose priority doesn't block an install that includes the exact version. Installing
(The result is that |
The proposed solution is to lower the priority on the repo files from Microsoft in order to give preference to the dotnet packages that come with the distro. With this known issue: in case a .NET version is not yet available from distro packages, pulling that version from the Microsoft repo will cause some/all versions not to work. Can the priority can be added into the repo file at https://packages.microsoft.com/config/rhel/7/prod.repo? |
It certainly helps the install experience. My understanding is this is waiting for review from the A few more things to think about:
More generally, I want to point out that nothing proposed so far seems to fix all problems--we still need documentation to help people fix up their installs and get the bits installed that they actually want. I think holding off on dotnet/docs#18347 is not good. |
[Triage] We need to break this into specific scenarios and prioritize them. Please consider Previews and future distro support. |
/cc @rconard |
FWIW, I found this answer on askubuntu to be a helpful read on this topic. The short answer is similar mechanism exist to control which package source is used/prioritized but may have the same potential issue of not having a single solution for all scenarios. Furthermore these settings are at the machine level, not the feed level. |
Source-built .NET is in Fedora and CentOS. There are numerous reports of people hitting issues when some packages on their machines come from the Microsoft repos and others from the distro archive. These packages don't work well together, i.e. they don't mix well. They have different dotnet roots, /usr/share/dotnet vs. /usr/lib64/dotnet. Here's one recent report: dotnet/sdk#15476
Additionally, packages from different distro repositories, i.e. Fedora and RHEL could cause similar issues. Packages are never meant to be mixed, only a single repository should ever be used.
We need to find a way to help customers avoid this issue. Better documentation could help, but is not the preferred or only solution. Other packages and application vendors could have found themselves in the same situation. We need to find ways to leverage distro and community knowledge to come up with a proper mitigation.
The text was updated successfully, but these errors were encountered: