hexxington

This is the "virtual monorepo", if you want to clone one repo and build the entire SDK product then this is the correct thing to checkout - but development work right now still happens in the separate project repos, of which there are ~20

Me. I directly refute this hunch. Nothing to do with xbox ever entered the discussion.

`dpkg -I foo.deb` tells you which control components are in a package. If it has a postinst, `dpkg -I foo.deb postinst` will show it to you.

No. The Winelib implementation fizzled over a decade ago. Mono's WinForms implementation is managed, invoking a cleanroom C libgdiplus.so/dlyib for GDI+ calls

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

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.

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. Minor point releases of seemingly innocent libraries can cripple an application with no visible recourse. As an ISV, you want tight control over the end user experience, and the only way you can achieve that is vigorous QA of the exact thing your users are running, top to bottom.

Banshee was badly hit by this, around the time it was under discussion as the default music player in Ubuntu - an innocent SQLite point release completely crippled the random button (30 second delays on next track, on a small library). Bundling would have avoided it, the distro model is why end users hit it. And anyone who's ever managed a Jenkins install knows minor point release updates can completely fuck the world (since so few Jenkins addins are subject to adequate CI)

I'm not new to the problem at hand, I've been packaging .NET apps on Linux for a decade. But this is the reality of where we are, especially when distro maintainers (quite reasonably) only want to ship one major version of any given library at once, and you just can't make any assumptions about your base system. Bundling means you can actually ship a _product_, and train your support staff on a single configuration that everyone will experience.

And the worst damage of the non-runtime components is mitigated via sandboxing.