A lot of the Debian patches are also things like removing phone-home, expiration timers, remote code exec via autoupdate, and other upstream nonsense that shouldn’t be in packages in the first place.
Gentoo has a much better track record of keeping packages vanilla, in part because patches are kept by default in the single Portage monorepo, so there is incentive not to dump huge patchsets in there. Only a few packages have significant Gentooisms maintained out of there (like the gentoo-sources kernel patchset, which as far as kernel patchsets go is still very light, and you can opt not to use it).
In 15+ years of using Gentoo I only recall two times their patches broke something for me. One, some obsolete crud in gentoo-sources broke booting without an initramfs on HP CCISS RAID controllers (because that's the only(!) block device driver that puts its kernel device names in a subdirectory). Two, a KDE Plasma patch to pull the right system Python version from the Gentoo infrastructure that manages that forked off a subprocess, but got fork() backwards, causing the "main" process PID to change and subtly breaking D-Bus policykit stuff due to security checks on the PID (aka: you can't mount devices from the system tray when the PulseAudio volume widget was loaded, how's that for a fun one to debug).
I don't recall Gentoo ever introducing a security issue, other than perhaps typical packaging mistakes (nothing comes to mind but I assume bad permissions have happened at some point, there's always some of those).
Not a bad track record for being my main workstation OS for a decade and a half.
[1]: https://www.schneier.com/blog/archives/2008/05/random_number...
Also, don't just blindly "fix things" because a tool complains. Understanding of warnings and error messages are important.
> Using uninitialized data as entropy source is an AMAZING idea in first place. “Fixing” or “unfixing” doesn’t make it any better.
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.
I've always thought that Fedora and Arch were both much more "upstream first" than Debian is.
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.
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.
In any case, good or bad, it's invasive.
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.
What I mean is taking one piece of software and splitting it apart into many libraries or binaries in a way that the upstream developer did not originally intend.
See some of the other responses.