Does the documentation default to Leap?

I’m trying to install PowerShell - openSUSE Wiki, but a prerequisite of PowerShell - openSUSE Wiki is DotNet - openSUSE Wiki, which states that the URI to the installer is https://packages.microsoft.com/config/opensuse/15/prod.repo

sudo zypper addrepo --refresh https://packages.microsoft.com/config/opensuse/15/prod.repo

However, considering that Index of config/opensuse/ contains both

would the 42.3 option be for Tumbleweed, whereas the 15 option for Leap, per

or should I just do as the documentation states?


I ask because I almost installed an old version of PowerShell once when trying PowerShell - openSUSE Wiki due to

so I’d like to confirm.

No. Leap 42.4 was the prior version of Leap 15.

https://en.opensuse.org/Lifetime

1 Like

Ah, so regardless of whether I use Leap or Tumbleweed, I’ll use /15/, @hui? Thanks.

Well, some requirements in this repository are not more present in Tumbleweed so you will not be able to install these packages in Tumbleweed. Like

user@uefi:~> zypper search --provides -x "libsemanage.so.1(LIBSEMANAGE_1.0)(64bit)"
Loading repository data...
Reading installed packages...
No matching items found.
user@uefi:~> zypper search --provides -x "libicu52_1"
Loading repository data...
Reading installed packages...
No matching items found.
user@uefi:~> 

The second one is for dotnet itself …

The openSUSE Wiki site you quoted says

While PowerShell is not provided by any official openSUSE repositories, there are still a few easy ways to it on openSUSE Leap and Tumbleweed.

Install directly from RPM

From RPM Directly

The GitHub releases page does not provide a native openSUSE RPM, but it does have a RedHat RPM that works well enough on openSUSE Leap and Tumbleweed.

I cannot see any hints that it requires DotNet to run this PowerShell package.

@susejunky, I deliberately linked to PowerShell - openSUSE Wiki rather than PowerShell - openSUSE Wiki for that reason:

While PowerShell is not provided by any official openSUSE repositories, there are still a few easy ways to it on openSUSE Leap and Tumbleweed.

  1. Install directly from RPM
  2. Install binaries from tar.gz (tarball)
  3. Install using sudo dotnet tool install --global powershell command

If you look at Microsoft documentation:

1 Like

I do not really understand what your point is. Both links in your post point to the same wiki page (which does not mention any real need for DotNet).

I guess you want to say that you would like to use the dotnet install method (which is not explained on this wiki page).

Any reasons why you don’t use the rpm installation method?

Did you try it before recommending?

user@uefi:~> sudo zypper install ./powershell-7.3.7-1.rh.x86_64.rpm 
[sudo] password for root: 
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides 'openssl-libs' needed by the to be installed powershell-7.3.7-1.rh.x86_64
 Solution 1: do not install powershell-7.3.7-1.rh.x86_64
 Solution 2: break powershell-7.3.7-1.rh.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c/d/?] (c): 
1 Like

I do not think @susejunky recommended anything. He explained that he tried to follow the information the OP provided and then came to a question.

1 Like

Yes.

If you choose Solution 2 it will install and can be used to some extend.

/opt/microsoft/powershell/7 # pwsh
PowerShell 7.2.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

   A new PowerShell stable release is available: v7.3.7 
   Upgrade now, or check out the release page at:       
     https://aka.ms/PowerShell-Release?tag=v7.3.7       

PS /opt/microsoft/powershell/7> help
PS /opt/microsoft/powershell/7> dir

    Directory: /opt/microsoft/powershell/7

UnixMode   User             Group                 LastWriteTime           Size Name
--------   ----             -----                 -------------           ---- ----
drwxr-xr-x root             root               24.09.2023 16:44           4096 _manifest
drwxr-xr-x root             root               24.09.2023 16:44           4096 cs
drwxr-xr-x root             root               24.09.2023 16:44           4096 de
drwxr-xr-x root             root               24.09.2023 16:44           4096 en-US
drwxr-xr-x root             root               24.09.2023 16:44           4096 es
drwxr-xr-x root             root               24.09.2023 16:44           4096 fr

And chances are that the broken symlinks

libssl.so.1.0.0 -> /lib64/libssl.so.10
libcrypto.so.1.0.0 -> /lib64/libcrypto.so.10

in /opt/microsoft/powershell/7 can be “repaired” …

However I have not tried so far (and probably never will because I’m not really interested in using PowerShell under Linux).

@susejunky for the likes of powershell and vscode, I just run the binaries from the downloaded tarball in it’s own directory…

pwsh
PowerShell 7.4.0-preview.3

PS /home/username> which pwsh
/data/applications/powershell-7.4.0-preview.3-linux-x64/pwsh
PS /home/username> 

I’m personally not interested in using PowerShell.

However for OP it might be interesting to know where you downloaded that tarball from.

I guess you are using this one.

1 Like

@susejunky yup, me either it’s just easier to test, also useful if on MicroOS and want to use the likes and no flatpak around…

@susejunky, look at the actual URIs! They have different fragments, and thus lead to different parts of the page when visited. It would have been very strange for me to override Discourse’s link naming with

``

when simply hovering over them would suffice. I suppose I’ll use a Text fragments | MDN too next time.

Yes, the links go to different locations on that wiki page. However that page does explicitly mention

… This page will only cover the first two installation methods. The last one requires the installation of the dotnet CLI and that is beyond the scope of this page.

Therefore I did not understand why you pointed to that page although you wanted to use the only installation method not handled by that page.

However it is up to you to choose the installation method you prefer. And in posts #11-#13 you can find out how to install a working PowerShell (by using a different installation method).

1 Like