3 ms·

> packages do not need to depend on the same dependencies It's a blessing, and a curse. In order to ensure the quality for all packages, now you have to keep a

> packages do not need to depend on the same dependencies It's a blessing, and a curse. In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check. A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now. This is similar to the reason that Debian doesn't accept packages which vendor any dependencies (similar to Fedora). > declarative package specifications I tried making RPM, .deb, and Nix packages, and I found Nix to be by far the nicest to work with.

stingraycharles 7y ago
While I agree with what you say, the dependency tree becomes more complex, I’ve found the alternative much, much worse. You can also “mimic” the old behavior by just forcing all the libraries to compile against a specific version of a library, thereby simplifying your dependency free again. In other words, Nix’ approach gives you the choice, while the current approach forces you into a certain direction.
m45t3r 7y ago
> A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now. This is untrue. Everytime that a package is updated, thanks to NixOS declarative build system, all packages that depend on it are also rebuild/updated. Unless you're pinning your derivations, it works even on custom packages created by you.
- rhn_mk1 7y ago
  That makes sense, but every pinned package contributes to the packaging burden. In order to reduce the burden to what traditional distributions have to deal with, pinning would have to be disallowed, which now resembles the traditional approach a lot, with one version per package.
  - m45t3r 7y ago
    Well, most packages does not pin dependencies. From the top of my head, proprietary packages generally pin dependencies, however in this case it is because proprietary packages are known to broke when a random library updates. When I was referring to pinning, it is mostly done locally. I do sometimes, for example, pinning a specific package to a specific commit of Nixpkgs, so I can either backport a new version or avoid some change that I don't want to deal at the moment.
debiandev 7y ago
> In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check Spot on. This creates a burden of work impossible to handle for any distribution. What really happens with the "everything goes" packaging (like throwing stuff in docker) is that nobody does security updates for most libraries.
- Nullabillity 7y ago
  What actually happens is that Nixpkgs usually bundles one version of $THING at a time, but as a user you can use, say, 19.09 as your primary system, but get your compiler from unstable because you need some cutting-edge feature, without worrying about dependency conflicts or unintentionally upgrading something else. Or maybe your FPGA programming software depends on some ancient version of QT from 2016, so you pull that Nixpkgs in for that package only.

stingraycharles 7y ago

While I agree with what you say, the dependency tree becomes more complex, I’ve found the alternative much, much worse. You can also “mimic” the old behavior by just forcing all the libraries to compile against a specific version of a library, thereby simplifying your dependency free again. In other words, Nix’ approach gives you the choice, while the current approach forces you into a certain direction.

m45t3r 7y ago

> A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now. This is untrue. Everytime that a package is updated, thanks to NixOS declarative build system, all packages that depend on it are also rebuild/updated. Unless you're pinning your derivations, it works even on custom packages created by you.

rhn_mk1 7y ago
That makes sense, but every pinned package contributes to the packaging burden. In order to reduce the burden to what traditional distributions have to deal with, pinning would have to be disallowed, which now resembles the traditional approach a lot, with one version per package.
- m45t3r 7y ago
  Well, most packages does not pin dependencies. From the top of my head, proprietary packages generally pin dependencies, however in this case it is because proprietary packages are known to broke when a random library updates. When I was referring to pinning, it is mostly done locally. I do sometimes, for example, pinning a specific package to a specific commit of Nixpkgs, so I can either backport a new version or avoid some change that I don't want to deal at the moment.

debiandev 7y ago

> In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check Spot on. This creates a burden of work impossible to handle for any distribution. What really happens with the "everything goes" packaging (like throwing stuff in docker) is that nobody does security updates for most libraries.

Nullabillity 7y ago
What actually happens is that Nixpkgs usually bundles one version of $THING at a time, but as a user you can use, say, 19.09 as your primary system, but get your compiler from unstable because you need some cutting-edge feature, without worrying about dependency conflicts or unintentionally upgrading something else. Or maybe your FPGA programming software depends on some ancient version of QT from 2016, so you pull that Nixpkgs in for that package only.