Nixpkgs Stdenv | 218 Members | |
| 69 Servers |
| Sender | Message | Time |
|---|---|---|
| 15 Nov 2024 | ||
| I guess there are two parts: 1) get fundamental infra inplace 2) an immense amount of grind to actually make it work sensibly in practice. | 11:10:34 | |
| I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000 Being able to put link-only flags in it for | 11:13:11 | |
| * I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000 Being able to put link-only flags in it for | 11:13:24 | |
| * I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000 Being able to put link-only flags in it for An alternative route would be to bracket these flags in | 11:14:38 | |
In reply to @emilazy:matrix.orgBtw the comment mentioned is not accurate | 11:14:41 | |
| Open Build System at least (optionally) rebuilds everything | 11:15:14 | |
| which comment? | 11:15:30 | |
| I don't see any mention of OBS there | 11:15:43 | |
In reply to @emilazy:matrix.orgThe comment you are linking to | 11:17:38 | |
| oh, "No other distro"? | 11:17:48 | |
| does openSUSE rebuild every downstream package for a one-byte security fix patch in OpenSSL that doesn't affect the headers or ABI? | 11:18:13 | |
| Just because other distros may pay the cost doesn't mean nixpkgs must also. | 11:18:36 | |
In reply to @p14:matrix.orgDon't get me wrong; I mean it's not something specific to Nixpkgs or Guix | 11:19:12 | |
| the world rebuilds are generally more gradual with other distros, AIUI | 11:20:18 | |
| involving manual pkgrel bumps etc. | 11:20:25 | |
In reply to @emilazy:matrix.orgI'm not sure if they added an automated function reference table or something similar when using the open build service. This process may be done manually, but based on my past experience with OBS, it should not be automatic | 11:20:49 | |
| Can we come back to what it would take to actually try and start implementing this? Is there a prototype repo or effort to try some of these ideas somewhere? | 11:21:08 | |
| OpenSUSE is just like us (crazy rebuilds, fancy automated QA service) | 11:21:09 | |
In reply to @p14:matrix.orgit's in my head :) | 11:21:20 | |
| Want to collaborate and try and prove it can be done? :) | 11:21:33 | |
| I would try and use it and break it. | 11:21:49 | |
| (and fix it) | 11:21:57 | |
here's the sketch: for every derivation producing a shared library, you want to use llvm-ifs to generate stubs from the libraries. you put those in dev, say | 11:22:08 | |
| Makes sense. | 11:22:17 | |
downstream derivations do not consume the library output at build time. they consume dev exclusively | 11:22:23 | |
and dev is ca-derivations | 11:22:32 | |
| (can you have only some outputs be CA? probably not. so it's a pain with Nix already) | 11:22:39 | |
| (but you can split it up into a separate derivation, etc.) | 11:22:44 | |
| For the prototype is there a reason you can't make whole derivations ca, even if they are not reproducible? | 11:23:20 | |
| you then, as part of the final package fixed-point-taking, join up every package that depends on a stub with the corresponding actual library output, and patch up the executables to point to the real paths. (optional: fancy static dynamic loading stuff goes here for perf) | 11:23:21 | |