Improving .deb

> So back to my main point, having the file size limit can force developers to do sensible things like solve the problems above.

If that was the case and how it worked in reality, they would have already fixed it. But they haven't: rather than getting a .deb package that can easily be installed like any others, they ship tarball installers with horrid self-extraction programs. In fact they probably wouldn't do it anyway even with that problem fixed, because they want one binary blob they ship to every platform, hence why they vendor everything under the sun. They have no interest in supporting multiple package formats. You're making a categorical error in thinking their goals (ship highly expensive, niche, proprietary software to users in controlled environments with support contracts) are the same as yours ("nice" Linux system integration). In fact the only people who suffer under this setup are the people who *do* want to be "nice" about Linux system integration, and ship .deb files of large programs/packages (for reasons that may not entirely be under their control.) Not Xilinx. And even if it wasn't a moot point, single device families (UltraScale+ IIRC) consume more space than is already allowed by a single .deb anyway, so there you go.

If you think a company like Xilinx that makes billions of dollars a year is going to change all of this because Debian has an artificial technical restriction on the size of .deb files: they won't, you're just not that important. They do not care about what Linux distro developers/users want or think is "ideal", and they have far more money and time than you do, so they can make it work. They have more money to burn than you have time to implement artificial technical restrictions to try and "force them" to behave. I don't know why people persist in believing this kind of trivial, easily-countered approach works: the entire premise relies on the faulty assumption that the dynamics of power are in your favor. They are not.

Huge proprietary applications should not use distribution package formats like .deb or .rpm anyway. More often than not they pollute the filesystem with their own idea of absolute directory structures, included libraries, broken dependencies and impossible un-installation.

That is exactly what we have appimage/snap/flatpak for!

As someone who maintains debian packages (for our company, not for Debian itself), uses Xilinx toolchains, AND has read a tiny bit about flatpack/snap/etc, I'm really torn.

As a pro-distribution guy, I like the benefits that package maintainers bring. On the other hand, I love that the Xilinx toolchain is entirely self contained: no need to mess around with figuring out which dependencies are needed (because god help them if they actually document those things). I totally see why flatpack (et. al.) are rapidly gaining popularity.