Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on.
We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
I assume folks downvoted this because they figured it was asking about Ruby or Bundler as upstream projects.
But looking at it from a perspective where Nixpkgs is the upstream: what does this introduce that would be unwelcome in Nixpkgs' bundlerEnv, or perhaps situated so it can share code with the existing implementations?
Sadly more and more upstream wants to have their cake and eat it to. Just look at Flatpak, that is all about moving the updating and distribution from distros to upstream.
Trying to put it politely, but your question seems a bit confused.
Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages.
There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages.
But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.
Gutting the functionality that upstream has built into a piece of software and then publishing it under the same name is dubious at best. If they want to go this direction they should publish as a fork under a different name so upstream doesn't get constantly barraged by complaints of users having issues.
This reminds me of the time years ago when the Debian maintainer of Chromium decided to unilaterally disable the ability to install extensions. Thankfully, more pragmatic minded people prevailed and the patch was reverted.
This also reminds me of a time many many many years ago when Debian removed the kernel interface that provided the ability to load binary firmware into network cards and broke networking for me.
"patching upstream" in this context means "applying patches to the upstream during packaging".
Nix and Guix require programs to work with a directory layout that differs significantly from the standard. Simple things like `#!/bin/python` don't work anymore, because they aren't explicit enough.
> All decisions related to dependency choices fundamentally belongs with upstream.
No. As a user I want dependency management (and all of software distribution, to be honest) to be handled by the party that's best able to keep things working while at the same time keeping them secure. Linux distributions have a much, much better track record at that than most upstreams.
It isn't even really a downstream project. This is like saying that third party Deb packages are downstream projects of Debian. They are just third-party packages you can install in Debian.
Yeah but also... “If you want to upstream it, take it” it's not really something where ehi forked is working hard to send it back upstream patch by patch...
I'm not sure why it's the author's responsibility to go setup a dozen different VMs. That really is the package maintainer's job.
Agreed. I do, however, expect upstream to accept reasonable patches from package maintainers to fix building bugs or make it easier for people to build packages themselves.
For the few times I've done it, I've had no trouble getting upstream to accept an updated .spec file (or even a barebones .spec file) that they can distribute in their targz to make it easier for the people who want to build their software as a package if their distribution doesn't provide one.
Of course, think about the relationship between Ubuntu and Debian. The idea is the upstream would be a fully open-source project that vendors build off of downstream. This way we can prevent vendors from subjugating a distribution like with Red Hat and CentOS and if a vendor pulls out of the market or goes out of business it doesn't take down the ecosystem with it.
There is no monolithic upstream organization. The real problem is that it's really hard work to upstream code, particularly when it touches core parts of the kernel. Look how long it took to get other invasive stuff like tickless or preempt RT.
But it got done, it just took time and patience.
And insulting the upstream people like this doesn't make your job any easier.
Upstream's irrelevant to a maintainer. Downstream? Maintainers typically know best, that's why the user chose that distro. I bailed on Debian when they decided to go systemd. That's Democracy.
We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
[1]: https://determinate.systems/posts/determinate-nix-installer#...
reply