Debian doesn't really work too well when you need multiple or new versions of software, or need something custom.
It's either spend a week wrapping your head around all the different ways of getting something to spit out a conforming .deb, or falling back to something like RVM + RubyGems / PIP.
The maintainer community is also reflexively defensive when they've broken something. The problem is never Debian breaking things into little unusable pieces, it's always upstream for not foreseeing how their software would be bastardized on Debian.
> Debian doesn't really work too well when you need multiple or new versions of software, or need something custom.
That's a fair complaint, and is also something of a complex issue, as there are tradeoffs between high quality integration, rapidly assimilating new stuff, the total number of packages in the repository, and so on.
However, Zed's mistruths about the nature of Debian (which is a volunteer-drive non-profit organization, not a business), are not:
"It is sadly pure business and has nothing to do with open source, quality, or culture."
"I did not write it to boost the Debian business plan"
I think the story of "forking" system packages for local use needs improvement.
And for all Debian's adherence to standards, it's unfortunate that one couldn't be agreed upon for source packages, 'apt-get source' is a mixed bag.
This makes it a royal pain to maintain forks, because now you have to be up on three or four source packaging formats, in addition to getting the final binary format to comply with the standards.
For the parts of the system where you don't care, using the distributor provided packages is fine.
But when you do care, it is often simpler to just use pristine upstream rolled into your own deb as a starting point for managing package versions at your site.
It's like the mainstream news media — anytime they report on a subject you know anything about, it's riddled with obvious errors. After this happens enough times, you know enough not to trust them about other subjects…
You're right that a bunch of what's broken in Debian stems from how naïve APT is — especially the lack of a slots mechanism (they just mangle the package names when there's no way to excuse it).
But the fundamental problem is purely social, not technical. Debian is always ready to introduce a new policy that would require them to screw with all the upstream packages (breaking things up, license wankery, dash, silence in valgrind, etc.)
Depressingly I find myself liking the way packaging is often done with RPMs, especially from vendors — they just make a directory in /opt that bundles any contentious dependencies, and just fucking works. Functionally there's almost no difference between RPM and DEB — it's purely social expectations.
It's either spend a week wrapping your head around all the different ways of getting something to spit out a conforming .deb, or falling back to something like RVM + RubyGems / PIP.
The maintainer community is also reflexively defensive when they've broken something. The problem is never Debian breaking things into little unusable pieces, it's always upstream for not foreseeing how their software would be bastardized on Debian.