Oof. I'd forgotten about that one. Tend to make things better, tend to. Just points out when you're doing systems level software development, how careful you must be.

Also, don't just blindly "fix things" because a tool complains. Understanding of warnings and error messages are important.

This comment sums my thoughts on that issue:

> Using uninitialized data as entropy source is an AMAZING idea in first place. “Fixing” or “unfixing” doesn’t make it any better.

They fixed a valgrind warning by blindly removing the affected function calls? Might as well reduce every program to an empty main() to enforce correctness.

Regarding Apache and nginx, you're referring to the sites/mods-enabled mechanism? Actually I really like that one compared to the "stock" way of one damn yuge httpd.conf - way more maintainable, no matter if in a Docker container creation script or in a bare-metal environment with Puppet provisioning.

Regarding exim... exim is one of a nightmare no matter how one looks at it. I hate it with a passion, no matter the distro.

/me raises hand

Yes, they do. And then they complain to you that this broke something: they split our package, from the main package A they split off parts into separate packages B, C, ... that depend on A. And then complained to us that B and C had a circular dependency and that this means we had to fix something. The audacity.

Our users still sometimes report issues where I immediately ask "are you using Debian or Ubuntu?" and the answer is usually yes: because guess what, they only install A (which matches our software's name) and then they miss the functionality which Debian moved into B, C, ... We actually print a warning about this when starting the software (along the lines of "Warning, B is missing, some things may not work as expected"), which then Debian patched out, calling it "misleading".

I've never had similar issues with any other downstream Linux distro.

So, no, I really can't agree with GP's statement.

Yep, had a bug very recently caused by splitting libllvm-dev and libclang-dev... guess what, libllvm-dev's CMake files depend on clang libs as they are all built together so if you only install libllvm-dev, find_package(clang) in CMake will error without any way to fix it from your code.

yeah, that's a good thing. because i do not need always dev-files or documentation or debug symbols on my machine.

all people are always about "slim systems" and alpine. but when debian does real engineering, then everybody complains it's complicated. that is a little bit annoying.

yes, debian is complex, but it's for a reason, since there are many requirements.

> Doesn't Debian sometimes go so far as to split software apart into multiple packages?

IMHO, this is the correct thing to do.

I've spent a considerable amount of time as both developer and systems adminstrator. Not quite DevOps, but I've been doing both since before that was a term.

Programmers don't often have that systems level view that is necessary for systems administration. It leads to myopia like this Ubuntu patch, and packaging is usually an afterthought to many programmers. It's that difference between a "project" and a "product."

So honestly, complaining that Debian splits things would be like complaining they don't deliver tarballs, because back before GitHub, that was how upstream "delivered" "packages" (how many people remember "tar -xzf package.tar.gz && cd package && ./configure && make"?). And before you bring up "missing files", you can do an "apt-file" to search for things and then install the associated package, assuming that it wasn't installed already as a Recommended package or in many, many cases, you are using a metapackage which contains the "full" package anyway.