hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
hamishmack has quit [Client Quit]
hamishmack has joined #nix-darwin
jtojnar has quit [Quit: jtojnar]
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
bluekelp has quit [Ping timeout: 246 seconds]
periklis has joined #nix-darwin
trcc has joined #nix-darwin
jtojnar has joined #nix-darwin
jtojnar has quit [Remote host closed the connection]
philr has joined #nix-darwin
trcc has quit [Remote host closed the connection]
trcc has joined #nix-darwin
johnw_ has joined #nix-darwin
trcc has quit [Ping timeout: 272 seconds]
johnw has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
aminechikhaoui has joined #nix-darwin
aminechikhaoui5 has joined #nix-darwin
aminechikhaoui5 has quit [Client Quit]
aminechikhaoui has quit [Remote host closed the connection]
jtojnar has joined #nix-darwin
johnw_ is now known as johnw
periklis has quit [Ping timeout: 252 seconds]
philr has quit [Ping timeout: 272 seconds]
<elvishjerricco>
destinations during eval?
<elvishjerricco>
LnL: I'm gonna try to make a module for time machine destination management. It's got a similar problem as user management: Destinations can be added and removed by users, so we need to record somewhere which destinations we're allowed to delete. Would you prefer me do this the way NixOS does users, by recording them in a file at activation time, or the way nix-darwin does users, by having a list of known
<LnL>
I'm actually not entirely sure how nixos does this
<elvishjerricco>
LnL: The state of which users are managed by NixOS is recorded in /var/lib/nixos
<LnL>
oh, with mutable files?
<LnL>
that's kind of weird
<elvishjerricco>
LnL: Yea but there's no other way to ensure declarative users get deleted when removed from the config without also requiring the user to keep deleted users listed in their Nix code, which is weird
<LnL>
sure, I've thought about adding them to the output but I don't think changing files is needed for that
<elvishjerricco>
LnL: Why not?
<elvishjerricco>
How else would you find deleted users?
<LnL>
you could do the same with an /etc file which gets symlinked atomically already
<elvishjerricco>
LnL: I don't follow
<LnL>
I like the idea but not the implementation
<elvishjerricco>
What is your proposed alternative?
<LnL>
seems to me like the nixos script treats /var/lib/nixos as a database that's updated updated during rather than reading data from the current system and replacing the symlink at the end
<LnL>
does that make sense or am I butchering my explanation?
<elvishjerricco>
LnL: Oh so you're suggesting reading from the symlink of the generation active before the new one, got it.
<elvishjerricco>
That seems fine. I can do it that way for time machien
<LnL>
yeah, write the metadata at build time instead of activation
<elvishjerricco>
LnL: Actually, that's not going to be possible for time machine. This stuff depends on an ID that I think time machine generates when you add the destination
<LnL>
ah :/
<elvishjerricco>
To add a destination, you refer to it by path (or url for network shares). Time Machine then creates an ID, and you have to use that ID to remove a destination
<LnL>
hmm, and you can't resolve the id based on the path? or could that result in problems
<elvishjerricco>
LnL: That could result in problems for the same reason that I'm not going to mess with exclusions yet: Things can move. The mountpoint can change, and Time Machine will still function properly by finding the disk via UUID.
<elvishjerricco>
It's possible that the ID is just the UUID of the disk, in which case I guess we could tell users they need to use that, but this won't work for network shares which generate an HFS sparse image with a new UUID when you add the destination
<LnL>
right not sure if it's possible without that then, maybe there's a similar case for nixos users
jeromegamez has joined #nix-darwin
trcc has joined #nix-darwin
trcc has quit [Read error: Connection reset by peer]
<elvishjerricco>
yuck this is actually pretty rough. Because mountpoints can change, I can't even think of how to denote the disk in the nix expression.
<elvishjerricco>
plus it has to be plugged in during first activation for it to work. Maybe I'll just... not automate destinations :P