The installer needs to support upgrades and fixes of installations #21

New issue

Open

opened 2024-07-23 11:13:49 +00:00 by jade · 1 comment

jade commented

2024-07-23 11:13:49 +00:00

Owner

nix upgrade-nix is kind of busted (see lix issue tracker) and so it really should be replaced by the installer. However the installer only really knows how to uninstall nix, which, on macOS, requires deleting the nix store volume and users and such, which need not be done for upgrades.

`nix upgrade-nix` is kind of busted (see lix issue tracker) and so it really should be replaced by the installer. However the installer only really knows how to uninstall nix, which, on macOS, requires deleting the nix store volume and users and such, which need not be done for upgrades.

👍 2

kfearsoff commented

2024-10-15 21:17:10 +00:00

Member

I think a lot of the code internals block this. I blame receipt.json for giving false sense of security. It is also used practically everywhere in the code, so we don't really have to write proper checks and error handling because we always just assume that receipt.json is right (or just fail loudly).

To put it bluntly: the Nix installation is pretty trivial in concept. We need to download a tarball, unpack it, create the filesystem tree at /nix, set permissions, and run some OS commands to finish Nix bootstrapping and to create service files. All of that can easily be done in idempotent ways, which will turn "upgrade" and "fix" into just re-running the installer (with maybe extremely small alterations).

The hardest bit here is creating and encrypting volumes, which only happens on MacOS. This is a one-time, irreversible operation. Honestly, we shouldn't even delete the volumes by default: it should be behind a flag.

I want to systematically go over all of the operations we do after receipt.json is nuked. I already made some progress on mv in code. Then, we'll just need a small patchset to make volume nuking optional, and we'll essentially have upgrade and repair for free.

I think a lot of the code internals block this. I blame `receipt.json` for giving false sense of security. It is also used practically everywhere in the code, so we don't really have to write proper checks and error handling because we always just assume that `receipt.json` is right (or just fail loudly). To put it bluntly: the Nix installation is pretty trivial in concept. We need to download a tarball, unpack it, create the filesystem tree at `/nix`, set permissions, and run some OS commands to finish Nix bootstrapping and to create service files. All of that can easily be done in idempotent ways, which will turn "upgrade" and "fix" into just re-running the installer (with maybe extremely small alterations). The hardest bit here is creating and encrypting volumes, which only happens on MacOS. This is a one-time, irreversible operation. Honestly, we shouldn't even delete the volumes by default: it should be behind a flag. I want to systematically go over all of the operations we do after [receipt.json is nuked](https://gerrit.lix.systems/c/lix-installer/+/2063). I already made [some progress](https://gerrit.lix.systems/c/lix-installer/+/1993) on `mv` in code. Then, we'll just need a small patchset to make volume nuking optional, and we'll essentially have `upgrade` and `repair` for free.

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix-installer#21

No description provided.