[davexunit]

>The thing about dependency bundling is it's the only way to guarantee that the app end users are running is the one your QA team tested against.

No, it isn't. See how Nix and GNU Guix solve this problem without resorting to bundling. Shipping a single binary to all systems is the use-case of proprietary software. Free software just needs distros that are more capable, that can handle multiple versions of the same dependencies, like Nix and Guix do. Bundling may be convenient, but it's harmful to the users.

[hexxington]

Guix solves literally zero of the issues I have, including anything I mentioned in my blog post. And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment.

C'mon, I _know_ bundling has issues, but it's like writing about the comparative merits of two cars, and someone saying hippos are cool. It's a non-sequitur. Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer.

[davexunit]

>And you conveniently ignored the real world problems with trusting someone else's dependencies I gave concrete examples of in my parent comment.

You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs.

>Wrapping up "configure && make && make install" in some Guile doesn't make it a useful answer.

Now you're just being demeaning and dishonest. You could insult any package manager by saying it's just a wrapper around make.

[hexxington]

> You can use whatever dependencies you'd like with Nix and Guix, that's a big reason for them to exist in the first place. To attempt to translate into Flatpak terms, the "common" runtime would be whatever part of the dependency graph you share with the upstream package collection. Share as little or as much as you'd like, you know the trade-offs.

If I can't rely on _specific versions_, I have gained nothing at all vs. using .deb. API changes are a real issue. Shit really does just suddenly break. Automake 1.11.2 arbitrarily removed something relied on mostly by GUI .NET apps (and also GRUB) - how would I have been able to anticipate that if I have no control over the build system being used during app installation? Changes to default GCC flags have broken Mono's garbage collector in the past. How can I be sure changes to the underlying libraries and toolchain _not provided by me_ won't break my app's installation or use by my users? I can't. So now I'm on a distro churn wheel, but where the target distro has almost no users, no traction, no user acceptance, no institutional knowledge, and a crap first-run UX that involves mangling bashrc.

Sorry, but it's just not up to scratch, and I would have scrubbed a project to use Guix within a week.

[davexunit]

> If I can't rely on _specific versions_, I have gained nothing at all vs. using .deb.

You can rely on specific versions of software build with specific dependencies, each using specific configure flags, a specific build system, etc. This is one of the major improvements over traditional system package managers that Guix and Nix offer. Both package managers, like Flatpak, can be used on top of any existing GNU/Linux distrubution, BTW, so you don't have to use a distro that so greatly offends like you like the one I help develop. You've drawn a whole lot of conclusions without knowing the facts and have been pretty rude in the process.

[orangeshark]

>If I can't rely on _specific versions_, I have gained nothing at all vs. using .deb.

Isn't that what you literally do in Nix and GNU Guix? You can create packages with specific versions of all your dependencies and use that for your package. I think by default they try to package and build with latest but can create packages for specific versions if needed.