Chromium Notes: Forking upstream software

Deltas (ie. patches you apply on top of upstream release when making a package) are not forks. Sane distros do that instead of forking for most packages if they have to change anything. Also, most package maintainers know the smaller the delta the less work they have to do, so it's in their own interest to minimise the changes (or try to push changes upstream). (Note: I'm not a Fedora user so can't say whether Fedora, referred to in the article, belongs in that group)

OTOH, code dumps of forked projects containing a mix of upstream and modified code without clear indication which code was pulled and which added/modified are a nightmare to work with.

[EDIT: not to say Google doesn't, as in the submitted article it's clear that they're trying.]

ffmpeg is one of the most notorious victims of this. Some examples of utter stupidity that has befallen many mainstream distros.

1. Arbitrarily disabling functionality due to worries about patents. For example, disabling all of the encoders, despite the fact that the decoders and encoders infringe by and large the same patents, owned by the exact same people, covered by the same royalty agreements. In other words, package managers at best attempting to look as if they were doing something when they in fact weren't, and at worst just being outright dishonest (Debian, some others). The actual reality is that it is probably impossible to compile ffmpeg without violating a patent.

2. Disabling all assembly optimizations because they saw it in a guide somewhere, and then wondering why everyone is unable to play back anything above SD video (too many to count).

3. Disabling all assembly optimizations because the package maintainer had a broken GCC installation and wasn't able to get the assembly code to compile properly (Macports).

4. Disabling all assembly optimizations because someone felt like hooking up USE flags for every single configure option, and then forgetting to set the defaults accordingly (Gentoo).

5. Packaging separate versions of ffmpeg for every single backend that uses it (gstreamer, mplayer, chromium) for no apparent reason other than to waste disk space. Oh, and configuring them all slightly differently, of course.

6. Packaging two separate sets of ffmpeg libraries, one with basic features and one with kitchen-sink features, but only packaging one actual ffmpeg frontend, resulting in a frontend that doesn't realize how it was actually configured (since the .so files are from the enhanced version, but the binary is from the non-enhanced version), resulting in very confused developers dealing with bug reports where the ./configure flags reported by ffmpeg are wrong (Ubuntu).

7. Dismembering ffmpeg into sub-library packages (libavcodec, libavformat, libavdevice), despite the fact that they come together and have interdependencies. This caused massive breakage when someone made a change to libavutil that only affected the internal API, and so the major version wasn't updated, and... (Ubuntu and many others).

What a mess.

(Note many of the distros I listed have since fixed their practices, so it's not all bad news.)