3 ms·

That's the great thing about Debian. A great community with a clear purpose. But I think their tooling and policies have become outdated, which prevents faster

by nextos 7y ago

That's the great thing about Debian. A great community with a clear purpose. But I think their tooling and policies have become outdated, which prevents faster progress. I wish they would switch to some Nix-like alternative, which was discussed in their developer list long ago. The genius of Nix is that packages do not need to depend on the same dependencies. Hence, the whole package tree does not need to be kept in sync. Another great advantage are declarative package specifications. I maintain several packages for NixOS, and a bot does auto-updates for me. I just check upstream hasn't introduced any malicious code. Lastly, shipping many "distributions" becomes trivial with Nix. A distribution is just a package channel plus a declarative setup written in a small half-a-page expression. So you can easily create a minimal Debian, a Debian with a GNOME desktop, a Debian with a Xface desktop, a Debian with a KDE desktop, etc.

rhn_mk1 7y ago
> 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.
zozbot234 7y ago
> So you can easily create a minimal Debian, a Debian with a GNOME desktop, a Debian with a Xface desktop, a Debian with a KDE desktop, etc. Um, you do know that Debian does this already, right? man tasksel
- ncmncm 7y ago
  They do, but it is not easy to do.
giancarlostoro 7y ago
> I wish they would switch to some Nix-like alternative, which was discussed in their developer list long ago. Ubuntu Snap does this. You may even be able to install Snap on Debian. Whats worse is the 'snap' package is unrelated so you may want to look it up before installing something unrelated.

by nextos 7y ago

rhn_mk1 7y ago

> 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.

zozbot234 7y ago

> So you can easily create a minimal Debian, a Debian with a GNOME desktop, a Debian with a Xface desktop, a Debian with a KDE desktop, etc. Um, you do know that Debian does this already, right? man tasksel

ncmncm 7y ago
They do, but it is not easy to do.

giancarlostoro 7y ago

> I wish they would switch to some Nix-like alternative, which was discussed in their developer list long ago. Ubuntu Snap does this. You may even be able to install Snap on Debian. Whats worse is the 'snap' package is unrelated so you may want to look it up before installing something unrelated.