Proposal: Drop PowerShell from Alpine and Ubuntu SDK images for .NET 9+

[richlander]

We added PowerShell to SDK images based on user demand in 2019. At the time, we made the choice to add PowerShell to all SDK variants. There was never a suggestion that PowerShell was needed by, for example, >50% of our user base. We should continue to offer PowerShell, however, it is no longer obvious we should offer it in all variants. Making our offering asymmetric w/rt PowerShell will offer users more choice (without increasing tag count).

We recently had to hold back the Alpine floating tag for .NET 6 due to PowerShell (#5196). Alpine is fast moving and considered a critical offering. We should ensure that all dependencies can move at the pace of Alpine for all of our Alpine images. If not, those dependencies should be removed (although PowerShell is our "foreign" dependency).

Size is another key topic.

• Alpine w/pwsh: 274.94 MB
• Alpine w/o pwsh: 259.27 MB
• Jammy w/pwsh: 313.52 MB
• Jammy w/o pwsh: 298.17 MB

Note: Sizes (compressed) are recorded from Docker Hub.

That's about a 15MB (compressed) savings. That's quite significant.

Continuing along the path of #4821:

• Debian should continue to be our default "all batteries included" offering, including PowerShell in the SDK image.
• Alpine and Ubuntu should be more opinionated, with no PowerShell in their SDK images.

There may be some users that use and prefer Alpine + PowerShell, for example. They can provision PowerShell themselves or switch to Debian. I think both are reasonable options.

I haven't completely given up on a distroless SDK (#4942), however, I think this proposal makes much more sense to consider first.

[lbussell]

[Triage] This would be a good size improvement over the existing SDK images for a feature that isn't used in a large proportion of builds. However, there is some ongoing work on making the SDK more "coherent" and thereby reducing the SDK's size or removing tools that don't make sense in containers. Re-evaluating PowerShell's inclusion in the SDK images should wait for those improvements so that there can be a larger difference between the proposed multiple SDK image variants.

@richlander is there an issue we can track for the SDK coherency work?

[richlander]

Closing, leaving dotnet/sdk#41128 as the tracking issue.