[DSR] - openSUSE Tumbleweed - x64

[RokeJulianLockhart]

1. Name of the Distribution

   cpe:/o:opensuse:tumbleweed

2. Version of the Distribution

   cpe:/o:opensuse:tumbleweed:20231006

3. Package Types

   1. Deb
   2. RPM
   3. Tar.gz
   4. Snap — Stop! Please file your issue in PowerShell-Snap instead.

4. Processor Architecture

   x86-64

5. .NET Core Support

   • The version and architecture of the Distribution is supported by .NET Core.

6. Distribution Requirements

   • The version of the Distribution is supported for at least one year.
   • The version of the Distribution is not an interim release or equivalent.

7. Exemption Justification

   My justification for the exemption is that Distribution Support Request - OpenSuse leap 15.3 #16446 (comment) doesn't apply to this, because that was Leap, which is mostly supported by the RedHat .RPM package, whereas Tumbleweed uses versions which are newer.

   My justification for the package is primarily Cannot set as login shell without manually adding to /etc/shells. PowerShell-Snap#101 (comment), although [DSR] - openSUSE Tumbleweed - x64 #20469 (comment) matters too.

8. Progress

   1. An issue has been filed to create a Docker image in PowerShell-Docker

9. For PowerShell Team ONLY

   1. Docker image created
   2. Docker image published
   3. Distribution tested
   4. Update packages.microsoft.com deployment
   5. Lifecycle updated
   6. Documentation Updated

[rhubarb-geek-nz]

I would suggest that building packages for rolling releases like tumbleweed are problematic because there is no one tumbleweed, it is continually changing. So the phrase "The version of the Distribution is supported for at least one year." doesn't really apply.

[RokeJulianLockhart]

#20469 (comment)

@rhubarb-geek-nz, indeed, but considering that the changes made aren't generally monumental - they're as iterative as any home user would want - it's more comparative to a very conservative ring of Windows Insider, like Beta (or even Release Candidate in some cases, since Windows is now fairly modular after its MSIX-ification). As long as you keep old versions of the published binaries available, nobody would ever beat you up over a version breaking.

[rhubarb-geek-nz]

nobody would ever beat you up over a version breaking.

I don't recommend that approach, people may be using the releases downloads to directly create docker images in automated systems.

opensuse leap would be a better target, then any build can be claimed to have been built and tested against a specific OS release

Rolling releases like Arch Linux, Kali and openSUSE tumbleweed should really take the responsibility to build and distribute PowerShell that is built with the current libraries. I don't think that the PowerShell team should be trying to play continual catchup.

[juvtib]

For others who find this thread, the PowerShell Snap is supported on SuSE.

One minor problem is that Snaps lag behind the GitHub release artifacts. See #19247 (comment)

> $PSVersionTable     

Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
OS                             openSUSE Tumbleweed
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

> snap list powershell
Name        Version  Rev  Tracking       Publisher              Notes
powershell  7.4.0    261  latest/stable  microsoft-powershell✓  classic

[RokeJulianLockhart]

#20469 (comment)

@juvtib, it also doesn't support being set as the login shell, per PowerShell/PowerShell-Snap#101 (comment). There are many reasons for me requesting this. Regardless, that issue appears worth reporting at https://github.com/PowerShell/PowerShell-Snap/issues/new?assignees=&labels=Needs-Triage&projects=&template=Bug_Report.yaml too.

[rhubarb-geek-nz]

See chsh -s /snap/bin/powershell: powershell is an invalid shell

My understanding is that snap packages are self contained hence cannot affect system files such as /etc/shells when installed.

Whereas RPM and Debian packages can update that in an automatic installation script

Given that snap packages are in their own file systems, if there was a problem mounting the snap package you may be locked out from logging in.

[rhubarb-geek-nz]

Yes, I see nothing about snap packages having installation scripts that can update the /etc directory, specifically the /etc/shells file. If you manually append the path to the executable to that file, can you then use it as a shell?

[rhubarb-geek-nz]

I don't know, @rhubarb-geek-nz. After all, just adding it to /etc/shells doesn't mean that it's immediately the login shell, right?

No, but it should mean that chsh should not complain so you can now change the default shell for a specific user.

Where does the 261 come from, is the path consistent across reboots? Are you supposed to use /snap/powershell/current/opt/powershell/pwsh ?

[RokeJulianLockhart]

#20469 (comment)

Yeah. That works, @rhubarb-geek-nz. Thanks. We probably should have discussed this at PowerShell/PowerShell-Snap#101 (comment). By the way, for future evaluators of this, you might want to visit https://forums.opensuse.org/t/how-to-ascertain-which-shell-is-the-os-default-shell/171686/1 if you didn't note the default shell prior to testing this.

[theJasonHelmick]

@RokeJulianLockhart - Thank you for this distribution request. We have no plans in 2024 to support this distribution.

[microsoft-github-policy-service]

📣 Hey @RokeJulianLockhart, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms