| 18 Jun 2025 |
 aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
Is this Linux-only, or are we considering other stdenvs (like Darwin) as well? The list is linux only | 17:28:37 |
 Randy Eckenrode | In reply to @aleksana:mozilla.org
The list is linux only My question was more about scope. Is reviewing other platforms in scope, or should that be a separate issue? | 17:30:40 |
| Randy Eckenrode | If someone later wants to take over one if these packages, would the stdenv team be dropped from them? | 17:31:17 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
My question was more about scope. Is reviewing other platforms in scope, or should that be a separate issue? You mean reviewing a package that builds on both linux and darwin? | 17:32:47 |
| Randy Eckenrode | In reply to @aleksana:mozilla.org
You mean reviewing a package that builds on both linux and darwin? Yeah, to see if there are other unmaintained packages in the major platform bootstraps. | 17:33:36 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
Yeah, to see if there are other unmaintained packages in the major platform bootstraps. It's up to them to decide. | 17:34:16 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | Currently I just want to reduce this kind of warning which is not actionable enough for ordinary users | 17:34:56 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
If someone later wants to take over one if these packages, would the stdenv team be dropped from them? Also the same | 17:35:40 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | We probably don't want to see someone who just added themselves to the maintainer list take up maintenance work, because merging r-ryantm unconditionally may still cause some chaos | 17:37:38 |
 Alyssa Ross | TBH you may be overestimating how much care goes into committer-merged updates to stdenv dependencies š | 17:40:02 |
| Alyssa Ross | (Not saying this isn't a good idea) | 17:42:00 |
|  tomberek joined the room. | 17:45:59 |
| tomberek | Would the stdenv folks be interested in a relocatable store, a relocatable Nix? The SC is exploring this as a possible roadmap effort and a big part of it would be building some momentum with the core+stdenv that requires more specialized experience. Don't have all the details figured out, but trying to gauge the interest. | 17:57:09 |
| Alyssa Ross | There are situations where it would be useful for sure but I'd expect it to be an immense effort | 17:58:02 |
 WeetHet | In reply to @tomberek:matrix.org
Would the stdenv folks be interested in a relocatable store, a relocatable Nix? The SC is exploring this as a possible roadmap effort and a big part of it would be building some momentum with the core+stdenv that requires more specialized experience. Don't have all the details figured out, but trying to gauge the interest. Not an stdenv folk but if I understand correctly, this would allow moving the darwin store out of a separate partition which would certainly be nice | 18:02:22 |
 emily | I've explored the idea (not in code, just in my head) and I would like it but I agree with Alyssa that it would be super tough in a lot of ways ā it's not just linker stuff but a bunch of ecosystems fractally expecting absolute paths to work, so I think it would involve substantial patching of many many packages | 18:03:14 |
| emily | (hopefully some of that could go upstream, but I know some projects are happy assuming absolute paths) | 18:03:31 |
| tomberek | It being a large effort is why we're trying to see if there is interest, what kind of funding would be needed, to do a feasibility analysis, etc. | 18:03:35 |
| emily | linker stuff is an issue too though: e.g., the path to the dynamic loader for Linux shared executables is absolute, and that's a kernel-level limitation. you can use $ORIGIN in library paths but not for the loader itself. I think you can work around it by linking binaries as effectively "static PIEs" with their own startup code that finds their dynamic loader and execs it | 18:04:37 |
| emily | but definitely pretty deep toolchain surgery to make that work, I've wanted to prototype it but no time | 18:04:53 |
| emily | (not sure if an explicit exec would always work without weirdness or if it'd have to be "load the dynamic loader into memory in userspace" which would be painful) | 18:05:46 |
| Alyssa Ross | My instinct here is that the cure is worse than the disease | 18:32:21 |
| Randy Eckenrode | In reply to @weethet:catgirl.cloud
Not an stdenv folk but if I understand correctly, this would allow moving the darwin store out of a separate partition which would certainly be nice Having it on a separate partition also comes with benefits (like being able to have a case-sensitive store). | 19:56:10 |
| Randy Eckenrode | Relocatable store seems like it would have the same difficulties as CA derivations with needing to update path references. | 19:58:13 |
| Randy Eckenrode | Iād rather see CA derivations stabilized if I had to choose. | 19:58:35 |
|  rosssmyth joined the room. | 20:48:00 |
| rosssmyth | I really like the work that has been going into stdenv recently. Primarily from Tristan Ross (though others too). I try silly stdenv stuff at work often and the work being done make it more possible to do in the future. | 21:02:18 |
| rosssmyth | thanks | 21:02:19 |
| rosssmyth | 376197 is one I am looking forward too because I tried wrestling pkgsCross in the past and the way the CPU attributes are setup now made it harder than it needed to be | 21:04:20 |
| rosssmyth | * 376197 is one I am looking forward to because I tried wrestling pkgsCross in the past and the way the CPU attributes are setup now made it harder than it needed to be | 21:04:24 |
