rollback to parent

[kirelagin]

I've just realised that nix-env --rollback rolls back to the profile with the previous number, while I expect it to roll back to a parent.

Here is what's unnatural:

• You have profile A.
• Modify it to get bad (broken) profile B.
• Rollback (you are on A now).
• Modify it to get profile C.
• Rollback.

At this point I expect to be on profile A while I'm on (broken) B and if I keep modifying the profile I will realise soon that all those profiles are inherently broken.

[lucabrunox]

AFAIK there's no track of a "parent".

[kirelagin]

Yeah, I think so.
This issue is intended to be quite a long-standing one ;).

[edolstra]

Yeah, I've wanted to fix this for years. The simple solution would be to store the parent generation number in a file like /nix/var/nix/profiles/default-66-parent.

[lucabrunox]

@edolstra or store it in the manifest.nix? so that's even read-only

[kirelagin]

Yeah, storing in the manifest sounds cooler. That's what I was thinking about when filing the issue.

[kirelagin]

Hm, but there is a problem: parent is a property of the symlink, not of the profile. That is, the same profile (same hash) can be obtained from multiple parents (different users having equal profiles). Right?

[lucabrunox]

@kirelagin if the parent is written to manifest.nix, then you can't have the same hash. Much like git commits.

[kirelagin]

@lethalman Ah, right. But then we'll get unnecessary duplication. Maybe having an intermediate object, containing a metadata (like parent, and probably something else) and a link to the profile could work. But that complicates things a little bit.

[lucabrunox]

@kirelagin I believe working with symlinks is more bug prone. Also it's not that we are going to use nix-env like we are using git for hot projects. It's not that you switch and then rollback every day I think. And even if you do so, there's the garbage collector and it's only about symlinks. I wouldn't bother.

There's more harmful duplication in general that simple user environments IMO

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I closed this issue due to inactivity. → More info

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/flakey-profile-declarative-nix-profiles-as-flakes/35163/3

[iFreilicht]

I've stumbled over this multiple times as well.

WRT storing it in the manifest, that would be a very messy solution. If you symlink to the previous generation, you can never delete any generation as they all depend on the previous one. If you simply store a name or generation index, then the profile depends on something outside of the profile.

The simple solution would be to store the parent generation number in a file like /nix/var/nix/profiles/default-66-parent.

@edolstra This would be my preferred solution as well. I'll have a look at implementing it.