4 ms·

Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will b

by mbakke 6y ago

Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it? 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".

georgyo 6y ago
You can also do this in nix. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
- mbakke 6y ago
  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".
  - deleted 6y ago
    [deleted]
- civodul 6y ago
  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-security-updates/ https://guix.gnu.org/en/blog/2016/timely-delivery-of-securit... .
viraptor 6y ago
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.
- kaba0 6y ago
  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.

by mbakke 6y ago

georgyo 6y ago

You can also do this in nix. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

mbakke 6y ago
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".
- deleted 6y ago
  [deleted]
civodul 6y ago
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-security-updates/ https://guix.gnu.org/en/blog/2016/timely-delivery-of-securit... .

viraptor 6y ago

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.

kaba0 6y ago
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.