| 15 Nov 2024 |
 p14 | I was originally going to stage this as moving it to the compiler wrapper, now I'm toying with just dropping it. | 11:42:18 |
| p14 | But maybe staging it by moving it to the compiler wrapper would be better if it needs to be reintroduced. | 11:42:39 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
actually patch up all the indirect references Thoughts: - we'd better take back control of how packages are provided to users from nix, especially in the nix3 shell and run
- pkgs is just one layer, but we can actually have several (or just two), and the bottom one is the unmodified build result, which is also stored in the cache.
- the process of wrapping or linking binaries can be written in an upper-level derivation, and these derivations should prefer local builds
| 11:47:16 |
 emily | you can do it at the fixed point level | 11:49:09 |
| emily | the resulting package set interface could be the same | 11:49:14 |
| emily | you'd probably want some splicing-y .__stubs type stuff 🫣 | 11:49:24 |
| emily | I think it's fine to do the relinking builds on Hydra though (probably) | 11:49:42 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Yes, we can still provide the default one | 11:50:11 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | It's just that we have to save two copies now | 11:50:27 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | And probably necessary to split out checkPhase so that the library itself doesn't show up in the build closure of stub derivation | 11:52:44 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Then with CA you can say it must be the same | 11:53:20 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | So no rebuilds | 11:53:26 |
| emily | checkPhase stuff was covered in the thread | 11:53:27 |
| emily | but really wants Nix changes too | 11:53:31 |
| p14 | In reply to @emilazy:matrix.org
definitely try 15 15 is fine as well | 11:57:53 |
| emily | 🤔 | 11:58:00 |
| emily | we could just drop it. I imagine wrapped compilers in development shells looking at /usr/include might be upsetting to some, though, if that's a thing that will happen | 11:58:33 |
| p14 | Oh right, that could be a problem if someone uses nixpkgs on a on-nixos system. :( | 11:59:00 |
| emily | well, but, we do pass all sorts of -isystem and -sysroot stuff | 12:00:11 |
| emily | so I dunno if it comes up or not | 12:00:19 |
| p14 | Still could be a problem if extra stuff is in the include search path | 12:00:31 |
| emily | extra stuff like? | 12:00:48 |
| emily | not denying it could be a problem, just want to understand the scenario better | 12:00:56 |
| p14 | At least it could manifest as the underspecified dependency problem: user thinks it's working, but it's only working by accident because they have stuff in /usr/include. | 12:01:04 |
| p14 | And then separately I don't know if we can assume those things defer to the wrapper's -i-flags in precedence or not. | 12:02:01 |
| emily | honestly the real solution is a proper sysroot or something (but there were issues with that too last time it was talked about in here) | 12:02:53 |
| p14 | How do you define "proper sysroot" and how does it help if the compiler can look somewhere you don't want it to look? | 12:03:18 |
| emily | really though there's so many ways for impurities to leak in outside of the sandbox | 12:03:20 |
| p14 | fair. | 12:03:29 |
| emily | In reply to @p14:matrix.org
How do you define "proper sysroot" and how does it help if the compiler can look somewhere you don't want it to look? it's not going to look outside of the sysroot if we provide one | 12:03:36 |
