How Update-Alternatives Manages Multiple Versions of Python, Node.js, and other Open Source Packages

parallel versionsAfter a friend installed Python 3.9 side-by-side with Python 3.6, he asked, “I noticed that the newer version, Python 3.9, became the default on my IBM i system. How did the default version get set?” We explained how IBM used the update-alternatives program to set the default version of Python and other open source software packages.

Update-alternatives helps organize multiple versions of open source packages, whether different versions of the same tool (like Python) or different implementations of the same standard (like a mailer or C compiler). Update-alternatives has long been the standard way to manage parallel versions on Linux systems, and now it’s used on IBM i, too.

Packages that support update-alternatives will use it when adding and removing alternative package versions. When packages are enrolled into the alternatives system (and possibly becomes default), you’ll see messages like these:

To list packages that can be managed, run update-alternatives from a PASE shell and pass the --get-selections flag:

To see all available versions of a specific package, or to change the defaults, run update-alternatives--config with the package name you’re interested in.  The following example retrieves all versions of python:

Note the values for Priority; in automatic mode, the package having the highest priority when enrolled becomes the preferred alternative automatically. In the example above, the highest priority is 309, making python3.9 the default version.

Not all packages provide support for update-alternatives; this is usually due to limitations in package management. For packages that aren’t managed through update-alternatives, you can run multiple versions in parallel by installing them in chroot containers.

2 replies
    • Calvin Buckley
      Calvin Buckley says:

      The npm link gets changed as well:

      $ update-alternatives –display node
      node – manual mode
      link best version is /QOpenSys/pkgs/lib/nodejs18/bin/node
      link currently points to /QOpenSys/pkgs/lib/nodejs18/bin/node
      link node is /QOpenSys/pkgs/bin/node
      slave npm is /QOpenSys/pkgs/bin/npm
      slave npx is /QOpenSys/pkgs/bin/npx
      /QOpenSys/pkgs/lib/nodejs12/bin/node – priority 12
      slave npm: /QOpenSys/pkgs/lib/nodejs12/bin/npm
      slave npx: /QOpenSys/pkgs/lib/nodejs12/bin/npx
      /QOpenSys/pkgs/lib/nodejs14/bin/node – priority 14
      slave npm: /QOpenSys/pkgs/lib/nodejs14/bin/npm
      slave npx: /QOpenSys/pkgs/lib/nodejs14/bin/npx
      /QOpenSys/pkgs/lib/nodejs16/bin/node – priority 16
      slave npm: /QOpenSys/pkgs/lib/nodejs16/bin/npm
      slave npx: /QOpenSys/pkgs/lib/nodejs16/bin/npx
      /QOpenSys/pkgs/lib/nodejs18/bin/node – priority 18
      slave npm: /QOpenSys/pkgs/lib/nodejs18/bin/npm
      slave npx: /QOpenSys/pkgs/lib/nodejs18/bin/npx

      As for things you install globally, those should be installed in the node version’s directory (i.e. /QOpenSys/pkgs/lib/nodejs18). I don’t recommend installing things globally though, because it can be really confusing to deal with for you and rpm. Best to install in the project’s directory, IMHO.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.