| 23 Dec 2024 |
 Whovian9369 | $ cd "$(nix eval --raw .#lts.src.outPath)"
$ rg -F 'Version="1.1.6"'
Aaru.Database/Aaru.Database.csproj
48: <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite.Design" Version="1.1.6"/>
$ rg -F 'Version="3.1.5"'
Aaru/Aaru.csproj
167: <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="3.1.5" />
Aaru.Database/Aaru.Database.csproj
45: <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="3.1.5"/>
46: <PackageReference Include="Microsoft.EntityFrameworkCore.Proxies" Version="3.1.5"/>
47: <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="3.1.5"/>
As far as I can tell, the only things that I'm changing are what I intend to, so I should be good.
| 04:01:22 |
| Whovian9369 | (Honestly I just prefer substituteInPlace since it leaves a cleaner directory, but honestly I should just use patch files instead since that will make the actual derivation cleaner.) | 04:02:14 |
 GGG | I myself prefer patch files because they ensure that things break if the file isn't the same anymore | 04:02:34 |
| GGG | instead of just possibly silently changing things they shouldn't | 04:02:47 |
| Whovian9369 | That's certainly a good point. Most of what I'm modifying (other than this) are hard to mis-patch so I'm not really worried, but hey that is still a very good reminder.
https://github.com/Whovian9369/aaru-nix-flake/blob/620ef8866395544b5aad55b7dac83fa63a988731/lts.nix#L36-L79 | 04:07:20 |
| Whovian9369 | On prerelease and git I'm only doing --replace-fail '{chash:8}' "${substring 0 8 src.rev}" which I'm pretty confident aren't going to mis-match at all even between updates.
(If those change at all, like if one gets removed, I'm sure that I'll figure it out pretty easily and add it to the extensive file list.) | 04:10:32 |
| 24 Dec 2024 |
 6pak | GGG replied to your question about buildPackages | 00:56:32 |
| 6pak | if after reading the link you are still confused, don't worry, I think everyone is | 00:56:42 |
| 6pak | imo the mess comes from the implicit splicing mechanic, it would be much clearer if you were forced to explicitly reference the package set but oh well | 00:57:54 |
| GGG | Huh, I thought `hostPlatform` was already the machine it's being built on | 01:00:43 |
| 6pak | hostPlatform is the host that will run the package | 01:01:04 |
| 6pak | buildPlatform is the host that is building the package | 01:01:17 |
| 6pak | targetPlatform is a special thing for target-specific packages, like the GCC compiler | 01:01:43 |
| 6pak | because you can build a GCC compiler on linux-x64 (buildPlatform) that will run on linux-arm64 (hostPlatform) that compiles binaries for linux-riscv (targetPlatform) | 01:02:38 |
| 6pak | so in most cases hostPlatform == targetPlatform | 01:02:52 |
| 6pak | in nixpkgs I think it's only GCC that uses targetPlatform? | 01:03:22 |
| GGG | God, this is so confusing | 01:03:34 |
| 6pak | llvm/clang can compile to multiple targets from single binary just fine | 01:03:35 |
| GGG | I think I get it now though | 01:04:11 |
| GGG | But yeah, most packages just outright don't work with cross from what I'm understanding then | 01:04:24 |
| 6pak | yup and add the fact that nativeBuildInputs/buildInputs silently use a hidden cursed splicing method that "convert" the package to a different platform set | 01:04:30 |
| 6pak | which is why a lot of build scripts in nixpkgs are broken | 01:04:42 |
| 6pak | because people are used to adding a binary to nativeBuildInputs of a setup hook or something and it working | 01:04:56 |
| GGG | Since I pretty much never see `pkgsBuildHost`/`buildPackages` being used | 01:05:04 |
| 6pak | and then they embed a package into a script literal in the same way and it breaks | 01:05:07 |
| 6pak | most packages don't have a lot of custom logic so they work finel | 01:05:45 |
| 6pak | * most packages don't have a lot of custom logic so they work fine | 01:05:47 |
| 6pak | and the mobile nixos[*] project put a lot of effort to make it work | 01:05:58 |
| 6pak | so most native stuff works | 01:06:01 |
| GGG | Issue is that there's no way to easily specify what should be taken from pkgsBuildHost and pkgsHostTarget | 01:06:27 |
