Stop producing RHEL-style RPM packages for aspnetcore-runtime?

[dagood]

The release process seems to have stumbled on the RHEL-style packages in a recent release (dotnet/core#3863), and @omajid brought up the question of whether they're necessary:

@dagood The "RHEL" style packages are for supplying the missing Microsoft.AspNetCore.App metapackage/framework missing in source-build, right? That's not necessary for 3.0 or later since source-build now includes ASP.NET Core. Maybe you can even stop producing those packages?

Aside:

/opt/rh/rh-dotnet20/root/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App/3.0.1/THIRD-PARTY-NOTICES.txt

The RHEL package convention would be to use rh-dotnet30 in that path for .NET Core 3.0. rh-dotnet20 is for 2.0 packages (only). For 2.1, that path would be /opt/rh/rh-dotnet21/..... For 2.2, that path would be /opt/rh/rh-dotnet22/... For 3.0, that path would be /opt/rh/rh-dotnet30/...

I'm not familiar with these packages myself.

The release process should be able to handle these being created, however stopping producing artifacts is typically a nice simplification if possible. 😄

/cc @leecow @dleeapho @dseefeld

[omajid]

For some context, and as I understand the history:

Back in the 2.x days of .NET Core, we (Red Hat) shipped .NET Core for RHEL 7, using source-build. At that point, .NET Core 2.0 had a runtime store including ASP.NET Core bits needed at runtime. source-build didn't build ASP.NET Core at that point. So users were left with a source-built .NET Core SDK that would build applications that wouldn't run since the runtime store was missing in that source-built SDK.

More details and the two workarounds we (Microsoft and Red Hat) came up with are captured in https://github.com/dotnet/designs/issues/10.

The second workaround from that issue:

Install the Runtime Package Store on target environments

Microsoft builds RPMs for the Runtime Package Store. These packages will be published on a Microsoft product feed (https://packages.microsoft.com/) and accessible via yum install (#2033).
[snip]
curl -sSL -o aspnetcore-store-2.0.0-rh.rhel.7-x64.rpm https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.0.0/gpg-signed/aspnetcore-store-2.0.0-rh.rhel.7-x64.rpm

This command has the same "rhel.7" suffix in the package name as the problematic aspnetcore 3.0 packages.

This workaround is no longer needed for 3.0 (and later) as I understand it. It should be possible to just delete (or stop producing/publishing) those packages.

[dougbu]

/cc @JunTaoLuo

This issue feel through the cracks. Right now installers like aspnetcore-runtime-6.0.0-alpha.1.20521.3-x64.rpm and aspnetcore-runtime-6.0.0-alpha.1.20521.3-rh.rhel.7-x64.rpm both end up in blob storage. @dagood @omajid if the second one is no longer referenced elsewhere, please let us know. We can remove the project pretty quickly.

FYI aspnetcore-runtime-6.0.0-alpha.1.20521.3-rh.rhel.7-x64.rpm is still built with <RpmPackageInstallRoot>/opt/rh/rh-dotnet20/root/usr/lib64/dotnet/</RpmPackageInstallRoot> instead of the /usr/share/dotnet/ default.

[omajid]

My quick thoughts:

1. These packages are not needed for 3.1 or later.

   The initial reason for creating these packages was that source-build was not producing the ASP.NET Core runtime store for .NET Core 2.x. This was fixed in 3.0. source-build'ing 3.0, 3.1, 5.0 and 6.0 all produce the ASP.NET Core runtime store/packages, which we ship in RHEL 7 (and RHEL 8). The gap that this RHEL 7 specific package addressed is no longer there. That means there's no need for Microsoft to produce something extra to fill that gap.

2. The RHEL package installation path is /opt/rh/rh-dotnet${DOTNET_MAJOR_MINOR_WITHOUT_DOT}/root/usr/lib64/dotnet

   Where DOTNET_MAJOR_MINOR_WITHOUT_DOT is just the major and minor version without a dot. So for 3.1, it is 31 and for 5.0 it is 50. For .NET 6, it would be /opt/rh/rh-dotnet60/..... If you install the runtime packages at /opt/rh/rh-dotnet20/...., they wont be picked up (because the installation is in a different location). I think they wouldn't help a customer using .NET 3.1 or later (even if the feature gap still existed, which doesn't, anymore).

If it's up to me: I would remove the RHEL 7 package (aspnetcore-runtime-6.0.0-alpha.1.20521.3-rh.rhel.7-x64.rpm and variants) for 5.0 (it's not too late for GA, right?) and 6.0.

[dagood]

5.0 (it's not too late for GA, right?)

I think it probably is, but I'm not really concerned... this has been around for a while and hasn't caused any more release problems since the first time as far as I'm aware. @leecow and @rbhanda may know more about the impact of having this package still around--perhaps there's more behind the scenes I'm not aware of.