It’s not really about how long you have to wait for a backport. Issues should be reported so they can be fixed for others.
3 Likes
I wouldn’t say it’s faster, unless you happen to have the right package with the right attention, same as in nixpkgs… Also, they only care about x86_64-linux, that makes the maintenance massively easier (in that respect - they pay for it in other ways, though).
Also, the “official” packages breaking AUR packages is considered working-as-designed, unlike nixpkgs, where we do at least try to avoid massive treewide breakages.
I am also using nixos-unstable, and most of the time it is really enjoyable. In my opinion, the update mechanism should be more egonomic for users and the ecosystem. I am thinking about something along the lines:
- I update my Flake lock files to latest unstable.
- I try to build the NixOS configuration Flake.
- Nix tells me: Hey, you are trying to build this derivation which Hydra has tried to build at that time in the past but has failed for this reason. If you still want to build, please pass the following flag.
Because usually, after updating my lock file, I start building, and only after downloading 3GB of data and my notebook fan starting to blow like crazy, I realize it is building Qt6, or SciPy, which is most often the sign of a build problem.
4 Likes
I think this is a great idea, honestly. It’s something the current binary cache protocol doesn’t have any support for, but it seems like something that could definitely be added. Of course someone needs to do the work both in Nix and in Hydra to make it so.
7 Likes