Source-build: Determine how to build portable assets for N when N-1 didn't build portable assets.

[dagood]

On Fedora, .NET Core 3.1 was bootstrapped without building portable assets (that source-build feature wasn't merged yet). Now, it fails to build portable bits because it requires portable prereqs from previously-source-built.

How can a distro maintainer bridge this gap? Can we use non-portable assets to build portable assets?

Or does a "build chain" that bootstrapped without portable builds always need to pass /p:SkipPortableRuntimeBuild=true?

Context starting here in Gitter: https://gitter.im/dotnet/source-build?at=5e6ab35f06898177494ab964

[omajid]

I guess I want to turn this bit around:

Or does a "build chain" that bootstrapped without portable builds always need to pass /p:SkipPortableRuntimeBuild=true?

The goal behind portable builds was to make it easier to bootstrap a distro using a prebuilt SDK. For example RHEL 8 is missing libraries like libunwind so a portable build makes it possible to build on RHEL 8 using a pre-built SDK. Once an SDK has been bootstrapped into a distro, what does the portable build offer? Is it worth building?

[dagood]

The goal behind portable builds was to make it easier to bootstrap a distro using a prebuilt SDK. For example RHEL 8 is missing libraries like libunwind so a portable build makes it possible to build on RHEL 8 using a pre-built SDK.

I'm missing the link between building source-build portable and the prebuilt SDK. The Microsoft SDK build is always portable, so I'm not seeing a connection there to source-build portable build. Are you maybe saying that we could use portable bits built for RHEL 7 to get together a portable SDK to bootstrap RHEL 8 with? (Which suggests a benefit to building portable during a distro build--right?)

Other than that though, I agree flipping the question is right--as long as everything using an N-1 has >= library availability, there doesn't seem to be a reason to include portable builds in that N-1.

/cc @dseefeld @crummel @adaggarwal

[crummel]

Are you maybe saying that we could use portable bits built for RHEL 7 to get together a portable SDK to bootstrap RHEL 8 with?

Yes, I think this is the idea. Portable MS official build -> portable source-built SDK -> RID-specific source-built SDK.

I think this is one of our ongoing troubles - we really only should have to build a portable version of everything once as source-built prebuilts, but:
a) we need to be able to build from scratch, including on banana linux, so we need to be able to build portable at any time. This really shouldn't be necessary; a 3.1.100 SDK should be able to build any 3.1.x build, except:
b) reference packages can change even during a major build. This is an ongoing problem because if sources change, our contributing repos may no longer be able to build correct reference packages, so even if we build everything we still rely on source-build-reference-packages to pick up packages.

Going forward:

• Portable/banana build could become non-default. We have a bootstrap script so this seems reasonable: add the portable build argument to bootstrap.sh and switch the default.
• We probably still want to have a portable version included in each previously-source-built version of packages (Private.SourceBuilt.Artifacts), so we may want to turn this on in CI in combination with https://github.com/dotnet/source-build/pull/1395.

[dagood]

Portable MS official build -> portable source-built SDK -> RID-specific source-built SDK.

This is what I'm missing: why is portable source-built SDK a step in here?

[crummel]

@omajid can correct me, but I think .NET Core's RID graph just runs behind. They were working on RHEL8.1 and Fedora 33 before CoreFX added those to the RID graph. Do we maybe just need to fix/extend our RID graph fixup?

[omajid]

Portable MS official build -> portable source-built SDK -> RID-specific source-built SDK.

This is what I'm missing: why is portable source-built SDK a step in here?

When we started packaging source-build 3.1, bootstrap wasn't working fully. So the default workflow in distributions like RHEL 8 are still just going from portable source-built SDK (downloaded by the tarball build, AFAIK) -> RID-specific source-built SDK on each build.

Once bootstrap is fully available/implemented, I think we should go from Portable MS official build -> RID-specific source-built SDK and then subsequently, -> RID-specific source-built SDK -> RID-specific source-built SDK and so on.

[crummel]

@adaggarwal I know we had some bootstrap issues, are those all resolved now?

If that's all fixed then this is really just defaulting SkipPortableRuntimeBuild to true, right?

[adaggarwal]

Boostrap leg is stable now. IMO, if we build stage-1 SDK for the Nth version of SDK and it produces portable bits. We should be able to use those bits to build the Nth version final-SDK. @dseefeld do you agree?

[dseefeld]

Yes. The bootstrap leg is stable.

[crummel]

After talking with Dan and Davis, I think this is what we came up with:

• We support two scenarios:
  
  
  
  • Somebody (not us) does a production build on a given RID, and then builds that tarball on the same RID. The only portable bits involved are the initial MS official SDK.
  
  
  • We ship a tarball that builds everywhere for any RID. It includes all portable bits and whatever RID graph fiddling is necessary. However, it has N-1 SDK requirements, including the N-1 portable bits, so you need to build the whole chain of portable bits and SDKs since bootstrapping.
  
  

So in this specific case: we added support for case 2, requiring portable bits, but since they're not available, the SkipPortableRuntimeBuild=true flag is the correct solution. This issue should determine whether case 1 or case 2 is default from here on out.

Does that seem reasonable @omajid?

[dagood]

I think that the build should not include the portable builds by default. Based on what I've seen so far (not much 😛), it seems like distro maintainers should not want portable builds. They slow down build time and increase artifact size, and they are only useful to distro maintainers if they want to use an SDK from one distro as an N-1 to start up a build chain on an incompatible distro.

Source-build maintainers ("we" above) should continue to build and publish tarballs that contain portable bits as necessary to let distro maintainers bootstrap on any portable-compatible distro. (E.g. "banana" Linux.) I do wonder if we can shrink the number of repos that actually need portable bits for the tarball to be compatible. (Do we have too many already?) I have a suspicion that our backlog of problems with RIDs make it seem like we need this in some cases where we actually don't. If that's correct, the divergence from default (having portable builds) may shrink and disappear over time.

[dseefeld]

Conclusion: A doc for distro maintainers should be created including this information.