Update Android RID graph to inherit from Unix

[marek-safar]

The previous Linux parent is incorrect as Linux libs won't work on Android

[marek-safar]

@ericstj

[ericstj]

This is a breaking change over 3.1.

previous Linux parent is incorrect as Linux libs won't work on Android

By this do you mean that they have a different binary format? What makes them not work? Can you imagine a lib built a particular way that would work?

[ericstj]

/cc @eerhardt who did this originally here: dotnet/corefx#28560

[lpereira]

It's the same binary format, but Android uses (by default) the Bionic libc instead of musl/glibc, and it's not the most standards-compliant CRT. (It had some "subtle" bugs in the past, such as memset() ignoring the byte to fill the buffer and always writing \0, breaking a lot of code that works elsewhere.)

[jkotas]

Using the same argument, linux-musl should not be child of linux.

[jkotas]

Can you imagine a lib built a particular way that would work?

No.

[ericstj]

What about IL that PInvokes to platform API? Would a single build work for Linux and Android or do people always need to special case.

Remember: any reuse makes the heirarchy useful. You can always target both in the non-reuse case regardless of heirarchy.

[jkotas]

What about IL that PInvokes to platform API? Would a single build work for Linux and Android

Yes, you can definitely imagine a single managed binary with PInvokes that works for both Linux and Android.

[marek-safar]

I think people have to always a special case to make it clear. Using the opposite argument you are saying that packages like https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64/ should just work on Android?

/cc @pjcollins

[am11]

See: #3075 (comment)

In the early days of linux-musl, thinking of RID as strictly measure of binary compatibility was considered narrow from the perspective of "constituents of an RID-specific nuget package". If the nuget package contain asset which does not depend on CRT and yet Linux specific, that needs to be accommodated by nuget as well.

It is another discussion that RIDs are not scalable: NuGet/Home#5862.

[eerhardt]

I think we are just rehashing the arguments in the conversation starting here:

#3075 (comment)

That is the conversation that changed android to be parented under linux instead of unix.

Using the same argument, linux-musl should not be child of linux.

100% agreed. And since linux-musl is a child of linux, the same reasoning made android be a child of linux.

[marek-safar]

Using the same argument, linux-musl should not be child of Linux.

100% agreed. And since linux-musl is a child of linux, the same reasoning made android be a child of linux.

They should both point to Linux parent if it was better understood by the tooling. Right now linux in RID graph does not mean any Linux but a specific kernel version with very specific userland libraries. That's not the problem of the graph but the fact we provide no good guidance on what for example linux-x86 RID actually specifies.

What is the correct fix?

Do we have to scan all nuggets and create issues for them to create fake android-* packages?

[ericstj]

Right now linux in RID graph does not mean any Linux but a specific kernel version with very specific userland libraries

What makes you say this? Because of the way that one package decides to use RIDs? That's not what defines the RID. The RID is just a tool. You decide how you want to use it in each package / system that makes use of it.

[eerhardt]

Because of the way that one package decides to use RIDs? That's not what defines the RID. The RID is just a tool. You decide how you want to use it in each package / system that makes use of it.

One problem that I see is our current tooling saying dotnet publish -r linux-x64 is the "Portable" way to publish an application. This does seem to indicate in our ecosystem that linux-x64 == linux-glibc-x64 and linux-arm == linux-glibc-arm. And I think this is the main reason people (including myself) think the linux RID literally equates to linux-glibc. It isn't just because "one package" decides to use the RID this way. (Although that "one package" is pretty important, since it is the root of everything .NET Core 😉.)

[steveisok]

@ericstj @eerhardt I think I understand enough of the points you're making. What's weird to me, and it does seem expected, is that for the android RID we are pulling in the Microsoft.AspNetCore runtime pack.

[eerhardt]

is that for the android RID we are pulling in the Microsoft.AspNetCore runtime pack.

Why are you referencing AspNetCore at all?

[steveisok]

We aren't. Both NETCore.App and AspNet runtime packs are being downloaded if you have a <RuntimeIdentifier> of android-arm64, for example. That's what seems weird to me.

[jkotas]

Yes, that's an annoying shortcut in the SDK. E.g. If you publish self-contained console app on Windows, the SDK will download all runtime packs it knows about (ie both aspnetcore and windowsdesktop) for you even though they are guaranteed to be not used. There is an issue about it somewhere explaining why it was done this way.

[eerhardt]

If you publish self-contained console app on Windows, the SDK will download all runtime packs it knows about

I had an offline conversation with Nick Guerrera on the same issue a few months back, and his response was:

We don't know if you'll have a transitive ref to asp.net when we download. We have to decide what to restore before we can know that. So it downloads all runtime packs.
We talked about ways to optimize it. If we get any more rutnimes, we will probably have to solve it.

cc @dsplaisted @wli3 - FYI

[dsplaisted]

I've filed the following issue to track figuring out how to handle the AspNetCore runtime pack for iOS and Android: dotnet/sdk#11289

[stephentoub]

@marek-safar, is this still relevant / are you still working on it? Thanks.

[marek-safar]

I'm not working on this but it's still relevant. If there is enough support to split linux RID to linux-glibc and linux-bionic I can do that.

[danmoseley]

My suggestion if this isn't being actively worked on is to open an issue and close this PR. It can be reopened later. It's hard to deal with so many active PR's.