
Chromium Notes: Forking upstream software - blasdel
http://neugierig.org/software/chromium/notes/2009/12/forking.html
======
blasdel
The lwn thread this responds to is hilarious:
<http://lwn.net/Articles/364528/>

The mainstream Linux distributions are the forkiest projects to ever exist, as
a point of immense pride: "we have 20k+ forked packages in our repository!".
Their whole sense of purpose is built around taking software from upstream and
then mutilating it arbitrarily:

    
    
      * License wank
      * Freezing it at an arbitrary version number for 6 months to 3 years
      * Patching it so that it works with your frozen dependencies
      * Independently backporting a random set of 'security' patches
      * Disabling features, often for ideological reasons
      * Dismembering it into separate packages
      * Rearranging its files to fit into a reverse hierarchy
        (which completely breaks any worthwhile language-specific module system)
      * Patching it to use a non-standard default configuration
        (often the personal preferences of the packager)
    

This is the _heat death of the universe_ calling the kettle black. It's a
lumber warehouse proprietor picking the mote out of a customer's eye. _I hope
their heads fall off._

~~~
DarkShikari
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.)

------
snprbob86
Interesting... It seems like there are real needs for conventions/standards
and tooling in several areas.

First, Windows desperately needs a proper package manager. There are several
projects in the space, but none as successful or prominent as apt, yum, etc.

Second, README files seem woefully insufficient for documenting where to send
contributions. Doesn't the Linux kernel (and Google internally) have the
concept of OWNERS files? If I recall correctly, Google's tools understand
these files for the sake of code reviews and bug filing. There is probably
also some space for an extended diff/patch format with code review comments.
Or a standard format for documenting a version graph.

Just spewing ideas...

------
alec
They have two mallocs?

