Add support for banana linux

[tmds]

.NET can't source-build on a distro it doesn't know (that is: not yet in the rid graph).

This is an impediment when building .NET on new versions of an existing distro, or when building it on a new distro.

The build should handle the unknown rid appropriately.
Package maintainers shouldn't have to become rid graph maintainers.

Tasks:

• runtime: support building an unknown rid (Pass TargetRid and SourceBuildNonPortable to the native scripts runtime#74504)
• runtime: make the built runtime know about the rid (Ensure shared framework consumes source-built RID graph runtime#53550)
• update source-build/installer
• add test

@dotnet/source-build-contrib

[tmds]

@crummel @dagood we are often running into issues with newer versions of Fedora due to the rid being unknown.
The suggestion here is to change /etc/os-release as part of one of the ci builds to ensure source-build works on an unknown glibc linux-x64.
Can we do this?

cc @omajid

[adaggarwal]

@crummel Chris Rummel FTE @dagood Davis Goodin FTE we are often running into issues with newer versions of Fedora due to the rid being unknown.
The suggestion here is to change /etc/os-release as part of one of the ci builds to ensure source-build works on an unknown glibc linux-x64.
Can we do this?

I think that's how dotnet-install.sh determines the os. Incase we replace it, we might need a file/placeholder that would contain the RID?

[omajid]

I think that's how dotnet-install.sh determines the os. Incase we replace it, we might need a file/placeholder that would contain the RID?

I think dotnet-install.sh falls back to linux-x64 rid correctly.

For example, arch-x64 RID doesn't exist in the RID graph, but we get past dotnet-install.sh on Arch Linux just fine: #1310.

[dagood]

I think that's how dotnet-install.sh determines the os. Incase we replace it, we might need a file/placeholder that would contain the RID?

It seems better to me to look at it from a dev's point of view: what do I expect source-build to do when it can't recognize my OS? My understanding is that the point of adding banana (which I think is a really good idea) is to find situations like that.

For the prebuilt SDK, I imagine I'll normally need linux-x64 (glibc). Then I'd probably want a non-portable build with my new RID in the right place in the RID graph that allows me to restore Microsoft assets if necessary for cross-RID publish, etc. Specifying those each time I want to build seems reasonable, because my OS is unknown (not mentioned in the sources). (Edit: Sounds like I may only need to specify the RID I want, or not even that.)

[crummel]

I like this idea, it'll keep us on top of new versions and unknown distros. It does seem like we'll probably have to soft-patch the RID graph though, unless something in the runtime changes to allow arbitrary unknown RIDs. We can try this out and see what all breaks.

[dagood]

we'll probably have to soft-patch the RID graph

I thought we were already doing that with:

source-build/repos/corefx.proj

Lines 97 to 107 in be813df

	<Target Name="UpdateRuntimeGraph"
	BeforeTargets="Build"
	Condition="'$(_IsBootstrapping)' == 'true'">
	<PropertyGroup>
	<RuntimeJsonFile>$(ProjectDirectory)pkg/Microsoft.NETCore.Platforms/runtime.json</RuntimeJsonFile>
	</PropertyGroup>
	<Message Importance="High" Text="Adding rid, $(TargetRid), to $(RuntimeJsonFile)" />
	<AddRidToRuntimeJson RuntimeJson="$(RuntimeJsonFile)"
	Rid="$(TargetRid)-$(Platform)" />
	</Target>

[crummel]

Oh, I think IsBootstrapping went away when we switched from BuildTools to Arcade. That should be an easy fix though.

[tmds]

(Edit: Sounds like I may only need to specify the RID I want, or not even that.)

Yes. Source-build should figure out the target rid from /etc/os-release and assume a parent of linux-{arch} (on glibc Linux).
As optional parameters, the user may want to name the target rid (e.g. rhel.8 instead of rhel.8.1)
And specify a list of parent rids.

For this issue, I think we can focus on patching /etc/os-release as a pre-build CI step. And verify we get an sdk for the patched os-release rid.

[tmds]

I think we can focus on patching /etc/os-release as a pre-build CI step. And verify we get an sdk for the patched os-release rid.

@dagood @crummel can we do this?

[dagood]

The approach sounds good to me, if that's the question. I don't know where it sits in the backlog... seems weird that @leecow is assigned and it's in a closed ZenHub epic. @crummel do you know the background, should it be unassigned to retriage or something like that?