Redesign Linux packages for side-by-side version installation #1309

Activity

1. Raghu Shantha (raghushantha)

   added

   Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a

   OS-macOS

   OS-Linux

   Area-SideBySiderelated to ability to run PS7 side-by-side with WinPS or different versions of PS7related to ability to run PS7 side-by-side with WinPS or different versions of PS7

   on Jul 7, 2016
2. Raghu Shantha (raghushantha)

   added this to the Aug17 milestone on Jul 7, 2016
3. Raghu Shantha (raghushantha)

   assigned

   Andy Jordan (andyleejordan)

   on Jul 7, 2016
4. andyleejordan commented on Jul 7, 2016

   

   Andy Jordan (andyleejordan)

   on Jul 7, 2016

   Member

   More actions

   I'm not sure I understand this need. What is the desire to have so many different PowerShell *nix packages?

   Developers needing different versions of PowerShell are going to consume NuGet packages through an entirely separate route, so that's not an issue here. Why would users need so many different *nix packages for PowerShell? If users absolutely need (and I don't know where this need is coming from for *nix) to install multiple copies of PowerShell, they would just leverage their packaging tools to install them to different locations.

   I think we should revisit this once we have customer input, and a release cadence 😄
5. Jason Shirk (lzybkr)

   added

   cut-aug17

   on Jul 7, 2016
6. Hemant Mahawar (HemantMahawar)

   removed

   cut-aug17

   on Jul 13, 2016
7. HemantMahawar commented on Jul 13, 2016

   

   Hemant Mahawar (HemantMahawar)

   on Jul 13, 2016

   Contributor

   More actions

   Per discussion with John W. Fawcett (@FawcettJohnW) , this should be enabled for initial release
8. Hemant Mahawar (HemantMahawar)

   changed the title [-]Our SxS story on *nix[/-] [+]Install PowerShell bits under appropriate folder on *nix[/+] on Jul 14, 2016
9. Hemant Mahawar (HemantMahawar)

   modified the milestones: v0.8.0This milestone has been deleted, Aug17 on Jul 19, 2016
10. Joey Aiello (joeyaiello)

    self-assigned this

    on Jul 21, 2016
11. Hitesh Raigandhi (hiteshraigandhi)

    modified the milestones: 6.0.0-alpha.8, 6.0.0-alpha.9This milestone has been deleted on Jul 28, 2016
12. lilyfang commented on Jul 30, 2016

    

    Li Li (lilyfang)

    on Jul 30, 2016

    Contributor

    More actions

    The current decision - No minor version, but just major version in subfolder, something like /opt/microsoft/powershell/6/.
13. andyleejordan commented on Aug 3, 2016

    

    Andy Jordan (andyleejordan)

    on Aug 3, 2016

    Member

    More actions

    Here's the rundown of the solution Joey Aiello (@joeyaiello) and I worked out:

    We will maintain the following packages:

    • powershell
      • named powershell
      • owns /usr/bin/powershell symlink
      • follows latest version
      • ships binaries for developer preview
      • installs binaries to /opt/microsoft/powershell/6.0-alpha
    • powershell6.0
      • named powershell6.0
      • owns /usr/bin/powershell6.0 symlink
      • version is 6.0
      • ships 6.0 binaries
      • installs binaries to /opt/microsoft/powershell/6.0
      • does not own /usr/bin/powershell
    • powershell6.1
      • named powershell6.1
      • owns /usr/bin/powershell6.1 symlink
      • version is 6.1
      • ships 6.1 binaries
      • installs binaries to /opt/microsoft/powershell/6.1
      • does not own /usr/bin/powershell
    • powershell7.0
      • named powershell7.0
      • owns /usr/bin/powershell7.0 symlink
      • version is 7.0
      • ships 7.0 binaries
      • installs binaries to /opt/microsoft/powershell/7.0
      • does not own /usr/bin/powershell
    • powershell-test (or alpha or preview)
      • named powershell-test (ditto)
      • owns /usr/bin/powershell-test (ditto) symlink
      • version is latest test/alpha/preview/nightly
      • ships latest test/alpha/preview/nightly binaries
      • installs binaries to /opt/microsoft/powershell/test (ditto)
      • does not own /usr/bin/powershell
    • etc.

    Obviously 6.0, 6.1, 7.0, etc. are not out yet, and we do not need to create these packages immediately. Open question is if we start making a -test package now, or wait until we have a repository.

    The primary goals of this approach are:

    • system powershell that is automatically updated (for the common scenario of a user just wanting powershell)
    • extra side-by-side explicitly versioned packages that do not conflict with powershell
      • meaning that they own only powershell6.0, so that workloads which require an explicit version will have the ability to use it without digging up an absolute path (this is similar to there being both python and python3 packages
    • satisfies both worlds by having a system powershell and side-by-side versions (not either/or)
    • ability to start by simply updating our current package, without requiring the immediate creation of the other packages (not an immediate switch to meta-package + dependency)
    • ability to update the powershell package to become a meta-package that simply causes a dependency to be installed (once a repository is available), but without having to do so immediately (as we don't have a repo yet)
    • all packages satisfy the Linux package managers' expectations
      • they do not conflict with each other
      • their package name and shipped binary match
      • they are self-contained and can be manually installed/removed
14. raghushantha commented on Aug 4, 2016

    

    Raghu Shantha (raghushantha)

    on Aug 4, 2016

    MemberAuthor

    More actions

    Proposal looks good

    • What is the purpose of the -test package and why do we need it?
    • I thought we had a proposal to add ability to get version info from powershell --version
      Useful if I want to know the PSVersion of default powershell before starting it.
    • How does OMI remoting registrations work with this model? Are the remoting binaries and configuration shipped as as part of individual powershell versions?
15. andyleejordan commented on Aug 4, 2016

    

    Andy Jordan (andyleejordan)

    on Aug 4, 2016

    Member

    More actions

    What is the purpose of the -test package and why do we need it?

    It's not something we need to decide on or create right now. I believe it will be useful to provide a simple powershell-test / powershell-nightly package (once we have a repository and nightly build infrastructure) with the latest builds for ease of testing. But it's for the future.

    I thought we had a proposal to add ability to get version info from powershell --version
    Useful if I want to know the PSVersion of default powershell before starting it.

    Yes, we have that proposal. But it doesn't affect this.

    How does OMI remoting registrations work with this model? Are the remoting binaries and configuration shipped as as part of individual powershell versions?

    Paul Allen (@paulcallen) will need to address this. Remoting in (Linux as server) binaries exist outside of PowerShell (they live in OMI) and need to know the location of the PowerShell libraries, which are well-known. Remoting out binaries (Linux as client) live with PowerShell, so are part of the package. For remoting in, logic will need to be added to the OMI provider to choose a PowerShell version from the list of available versions.
16. Andy Jordan (andyleejordan)

    changed the title [-]Install PowerShell bits under appropriate folder on *nix[/-] [+]Redesign Linux packages for side-by-side version installation[/+] on Aug 10, 2016
17. Andy Jordan (andyleejordan)

    added

    3 - Working

    and removed

    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a

    on Aug 10, 2016
18. Andy Jordan (andyleejordan)

    closed this as completedin #1717on Aug 11, 2016