| 20 Mar 2022 |
 Arian | follow-up. :P | 08:17:13 |
| Arian | Another follow-up I'd want to do is evangelize https://systemd.io/DISCOVERABLE_PARTITIONS/ . I guess that could be part of adding repart support (as it uses it by default) | 08:17:38 |
| Arian | it makes systemd initrd automatically discover LUKS partitions etc without cmdline or /etc/fstab hints | 08:17:58 |
 @elvishjerricco:matrix.org | Yea I'm iffy on that. The systemd people seem to really like it, but it seems antithetical to NixOS's "declarative everything" approach | 08:18:26 |
| Arian | yeh true | 08:18:40 |
| Arian | my only gripe is whether having rust in the bootstrap path is a good idea... | 08:22:09 |
| Arian | But given we were eager to add it to nix as well I think that ship has sailed. And rust bootstrapping is in sorta-ok shape | 08:22:35 |
| Arian | (I think Guix people figured out bootstrapability of rust) | 08:22:51 |
| Arian | Yeh actually not gripe at all. Go Rust | 08:23:14 |
| @elvishjerricco:matrix.org | Arian: Rust has been in the bootstrap path for quite a while now because it's needed for spidermonkey which is needed for... polkit(?) or something | 08:25:16 |
| @elvishjerricco:matrix.org | But given we should be caching this tool, users should never end up downloading a rust tool chain to build their systems | 08:25:51 |
| Arian | oh yeh polkit... great =) | 08:26:44 |
 @janne.hess:helsinki-systems.de | In reply to @arianvp:matrix.org
But given we were eager to add it to nix as well I think that ship has sailed. And rust bootstrapping is in sorta-ok shape It got removed iirc and is now only used for the docs | 09:44:35 |
| @janne.hess:helsinki-systems.de | In reply to @elvishjerricco:matrix.org
Arian: Rust has been in the bootstrap path for quite a while now because it's needed for spidermonkey which is needed for... polkit(?) or something Andy is in the process of replacing that for duktape though | 09:44:58 |
| @janne.hess:helsinki-systems.de | (not saying I don't like the language but I don't think it's part of bootstrap rn) | 09:49:17 |
 ius | In reply to @arianvp:matrix.org
oh yeh polkit... great =) Note that polkit master includes support for duktape instead of spidermonkey, which is a reasonably small C++ JS implementation. That's how I avoid having to build llvm/spidermonkey on (terribly slow) RISC-V | 10:45:42 |
| ius | oh doh, that's what Janne Heß mentioned as well | 10:48:08 |
| Arian | I see. | 10:48:23 |
| @janne.hess:helsinki-systems.de | #164943 doesn't add a way for me to use the initrd-ng stuff without systemd, right? ElvishJerricco | 13:35:55 |
| @janne.hess:helsinki-systems.de | ah kinda. I can just call makeInitrdNG with my contents and mkForce that into system.build | 13:37:24 |
| @janne.hess:helsinki-systems.de | I was just wondering about that because it provides future proofing (maybe we want to use another init system in 10 years for stage 1, who knows) and also adds flexibility for very, very obscure things (I may or may not be doing with the current stage 1 👀) | 13:38:15 |
| @janne.hess:helsinki-systems.de | also while we're touching everything, it might be wise to fixup the type of the contents passed to make-initrd(-ng). It's currently List of { object = path_or_derivation; symlink = "/path"; } which is horrible imo because it doesn't allow for overriding. I think something like { path_or_derivation = { symlink = "/path"; } would be nicer for that and would still provide a way to add more attributes in the future. | 13:40:58 |
| @janne.hess:helsinki-systems.de | * also while we're touching everything, it might be wise to fixup the type of the contents passed to make-initrd(-ng). It's currently List of { object = path_or_derivation; symlink = "/path"; } which is horrible imo because it doesn't allow for overriding. I think something like { path_or_derivation = { symlink = "/path"; }; } would be nicer for that and would still provide a way to add more attributes in the future. | 13:41:15 |
| @elvishjerricco:matrix.org | Janne Heß: you can't have a derivation as a key of an attrset | 13:53:06 |
| @janne.hess:helsinki-systems.de | ah right, damn it | 13:53:33 |
| @elvishjerricco:matrix.org | I thought about finding something like that and honestly this just really isn't ever going to need to be overridden like that | 13:53:43 |
| @janne.hess:helsinki-systems.de | hah I have the perfect idea. Just do objects = map lib.mkBefore [, that should make it as overridable as system.build was in 21.11 | 13:54:52 |
| @janne.hess:helsinki-systems.de | also, yes. I know how incredibly ugly that is | 13:55:28 |
| @elvishjerricco:matrix.org | The thing is that object is always going to be copied to its original path, so there's nothing to override there, and you can always specify the same object more than once to have more than one symlink. So the only overriding we can't do is removing a symlink | 13:56:32 |
| @janne.hess:helsinki-systems.de | Hm you are probably right and my desire to have the ability to remove files is too much me holding on to the things I had previously but that I didn't really need | 13:57:46 |
