4 ms·

I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstract

by mbakke 6y ago

I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems). You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.

viraptor 6y ago
Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)
- 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

viraptor 6y ago

Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)

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.