Debian still likes to Debianize things too much sometimes.

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.

Yeah, IME, Debian is about the least invasive distro. Their patches tend to be a) minimal and b) only make things better.

Except for that one time[1].

[1]: https://www.schneier.com/blog/archives/2008/05/random_number...

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.

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.

A reference to https://news.ycombinator.com/item?id=25052001 ?

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.

uuh, no. perhaps it was initialized with zeros before. or with highly structured data. uninitialized data is not the same as external noise. i am rather glad, they think of that, it was a shame, that they oversaw this.

I disagree, what they do to Apache, nginx and especially Exim is very invasive and doesn't bring any actual benefit. They even had to write a program to modify the Exim configuration after they made it impossible to do it by hand.

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.

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

I've always thought that Fedora and Arch were both much more "upstream first" than Debian is.

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.

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

Wow, this Debian hack really makes life difficult for end users :( > 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". >

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

Yes but see the other responses for examples of this "going wrong".

In any case, good or bad, it's invasive.

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.

Also, removing -dev packages and compilers is one of the usual hardening steps, to make it harder for an attacker to establish a foothold and build tools.

No, that's not what I mean. Most distributions do things like splitting dev-files and debug symbols and documenation.

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.