And it depends on your use case - whether you want to guarantee exactly the same behaviour and ship all the dependency updates yourself; or do you want to have less maintenance burden and trust the base layer to not change behaviour.
In a tightly controlled environment inside a company where the update mechanisms are preconfigured / enforced, I'd go with nix model. When distributing an app to people on the internet, I'd choose flatpak model.
But you simply don’t have to worry about it. You test it on the next LTS release of nixpkgs and that’s it. Your user may download a bit more data, but I found that nix is lightyears faster then fedora’s build tool, and on par with arch, while not polluting the whole filesystem with random files. I don’t see where would you need more maintainance.
You can also do this in nix.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
Oh, cool. I don't see it being used anywhere though, apart from being available as a system activation function?
In Guix grafts are used rather extensively, mainly for security updates, but also command-line transformations such as "--with-debug-info".
It wouldn't be a nice interface for packagers to use.
More importantly, it's not enough to implement grafts because it's not recursive, as discussed at https://guix.gnu.org/en/blog/2016/timely-delivery-of-securit... .
Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".