> As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development.

Is that the case for some specific languages? -dev packages for C and other compiled libraries do not include the full source code of the library. Normally they only include the headers, pkgconfig, and similar files.

> Libraries are not upgradeable due to how other packages depend on them.

Got some examples where it's a problem and not an actual dependency issue?

> Got some examples where it's a problem and not an actual dependency issue?

Try to recompile mesa or say, just the demos (aka glxgears) :) Worst case scenario for Debian dependencies.

I meant an example of what the issue is. Glxgears seems to have reasonable dependencies (https://packages.debian.org/buster/mesa-utils) gl1 and glu1 are not even restricted on versions.

I regularly recompile mesa on my Debian-based phone and I'm not exactly sure what you mean. It goes painless.

So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

> So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

Header files are literally less than a couple kB per package, and Megabyte-sized headers are the exception for huge frameworks like QT or GACL. Arch packages don't ship the source codes, only the binaries (.so files) and headers (.h files).

Overall, the /usr/include folder on my system has less than 230MB, which is a damn lot because I have all kinds of compilers, programming languages and libraries installed. I even have 32Bit and atmel libraries installed because I do embedded reverse engineering and cross-compiling development on other architectures; so I also have gcc, LLVM, rust, go, C/C++ and other programming languages and their dependencies installed. So it's very likely much less than that for others.

If you cannot afford that, you should maybe choose another, smaller, distribution like "Damn Small Linux", Alpine or similar. Debian wouldn't be a good choice for that matter anyways.

I’m not sure what the argument is here. Either the header files you have to download are big so you shouldn’t have them on your system if you don’t need them, or they’re not big so it’s not a problem to just use the apt command to download all the header packages you need to build the package you want.

> Arch packages don't ship the source codes

Neither do Debian's -dev packages.

I don't have any Debian machine that doesn't end up with build-essential and dozens of header packages installed; it just comes up too often. Adding the header files directly to the packages saves time and frustration, and probably even saves space since a lot these packages are 50% overhead (dpkg meta files, db entries, etc.) by size.

I don't install build-essential on a server, in a container, on a VM, etc. It really matters in those places. If you combine them then you lose the ability to deploy a small rootfs.

Servers, VMs etc. always end up getting build-essential to handle random python/ruby/npm/... package installations, as the shipped versions are hopelessly outdated and creating your own debian packages for all of them is about as enjoyable as performing appendix surgery on yourself.

Multi-stage builds do make it a bit easier to get rid of them for containers, yes, but during the build stage it's still required.

I refuse to believe that these meta files and database entries are occupying anywhere near a relevant amount of space.

Relatively.

Absolutely, it's negligible - because the space consumption of header files is also negligible. It's such a bizarre design choice to split out a single 30 line .h file into a separate package.

I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid.

I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.

You don't need to chroot for cross-compiling, Debian supports multi-arch for most of the packages. You just install the cross-compiler, the cross-libc and all native development packages for the architecture you're building for.

Last time I tried that I had bad problems with package conflicts trying to overwrite files, but it was a while ago and maybe I was doing something wrong, I'll give it another shot.