Nix-env : how i can install two differents versions of the same software inside a user


I want install in the same user two version of the software.

I think than specify the --profile directory was the solution.
but this command :slight_smile:
nix-env -iA nixos.postgresql_10 --profile ~/app/binary/
retrun: :frowning:
error: ‘/home/postgres/app/binary’ is not a symlink

So my question is :
How i can install two version of the software binary?

Why i want to do this ?
To use the pg_upgrade binary to migrate db from one version to another.


It doesn’t really make sense to install multiple versions of packages, because you can’t have more than one version of a binary in your PATH.

I assume you intended to call pg_upgrade after installing like ~/app/binary/bin/pg_upgrade? I recommend either calling the binary directly (which doesn’t install anything):

$(nix-build --no-out-link '<nixpkgs>' -A postgresql_10)/bin/pg_upgrade

Or running the binary in a nix-shell, which also doesn’t install anything:

nix-shell -p postgresql_10
[nix-shell:~]$ pg_upgrade

For completeness’s sake: you can create another profile, but it mustn’t already exist as a directory or file:

$ mkdir profile1
$ nix-env -p profile1 -iA nixos.hello
error: '/home/linus/profile1' is not a symlink
$ nix-env -p profile2 -iA nixos.hello
installing 'hello-2.10'

Note that this may not produce your desired behaviour though, for several reasons:

  • It will not create garbage collection roots for the profile, meaning that its dependencies may be removed from under your feet during a garbage collection;
  • It will keep historical versions of the profile right next to it. For example, the successful invocation of nix-env in my example created profile2-1-link in addition to profile2;
  • The profile’s bin directory will not be in your PATH, nor will any other relevant environment variables be set, so you should have another use for putting them in a profile.

The first two issues can be solved by first creating a symlink to /nix/var/nix/profiles/per-user/$USER/profilename: ln -s /nix/var/nix/profiles/per-user/$USER/testprofile profile3 && nix-env -p profile3 -iA nixos.hello.

Hi Infinisil :wink: thank for your reply.

I sorry , but the command pg_upgrade have need of a path on the two versions.
pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin

On Debian and all others distributions you can install several version.

You can have need to manage a cluster DB in 9.6 and one in 11.


Hi Linus,

In case of postgres database software, we don’t install the same version.

We need to have the path on the oldversion and the newversion.

I search how resolve this problem inside nixos.

Nix-shell seem a way.

It’s OK

I install postgresql 10 default profile

i launch a nix-shell with -p postgresql_11

and create a link .
ln -s /nix/store/88yxsbssvzrv22wymwy7m7ghpxy2fgnj-postgresql-11.4 pg11

after several step …
launch the migrate from 10 to 11. :slight_smile:

./app/binary/pg11/bin/pg_upgrade -d ~/app/data/DB1 -D ~/app/data/DB2 -b /home/postgres/.nix-profile/bin -B ./app/binary/pg11/bin --link
Performing Consistency Checks

Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Creating dump of global objects ok
Creating dump of database schemas
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade

Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluster
Adding “.old” suffix to old global/pg_control ok

If you want to start the old cluster, you will need to remove
the “.old” suffix from /home/postgres/app/data/DB1/global/pg_control.old.
Because “link” mode was used, the old cluster cannot be safely
started once the new cluster has been started.

Linking user relation files
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok

Upgrade Complete

Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:

Running this script will delete the old cluster’s data files:


If you want to run a binary from a given package it’s generally simpler to write this like nix run nixpkgs.postgresql_10 -c pg_upgrade.


Hello lilyball,

Thank about your reply.
but the pg_upgrade command need several args as you see below

to bypass I created a symbolic link on the binary of the postgresql11 version.
But it’s not very clean.

Isn’t it possible to create it with a nix command?


Hi all

Creating links like these is not a solution
because the next system cleanup will remove the packages in the /nix/store

How i can create profile on these links ?


You can pass additional args to the nix run command. That said, the -b /home/postgres/.nix-profile/bin has me a little concerned, as nix run doesn’t touch that symlink.

You don’t have to “install” things:

$(nix-build '<nixpkgs>' -A postgresql_11)/bin/pg_upgrade --link \
  -d ~/app/data/DB1 -D ~/app/data/DB2 \
  -b $(nix-build '<nixpkgs>' -A postgresql_10)/bin \
  -B $(nix-build '<nixpkgs>' -A postgresql_11)/bin
nix-build '<nixpkgs>' -A postgresql_11 -o pg11
nix-build '<nixpkgs>' -A postgresql_10 -o pg10

Will create symlinks to the packages which are also GC roots, i.e. their dependencies won’t get removed by the garbage collector until the symlinks themselves are removed (with the caveat that the “removal detection” is fairly naïve and will consider the symlink removed if it is moved/renamed as well).


Hi Linus,

Your solution work fine :+1::+1::+1:

Thank a lot.