Chromium: Why it isn't in Fedora yet as a proper package
People keep asking me about chromium (the generic name for Google Chrome), specifically, when it will be part of Fedora proper. Why do they ask me this? Well, because I've been packaging built-from-source-against-Fedora RPM packages here: http://spot.fedorapeople.org/chromium/
Here are a list of the roadblocks to proper inclusion:
* Chromium isn't stable. That's not to say that the code doesn't work, or even that it is overly buggy. The fact that I'm able to package it implies a certain measure of stability. What I mean by this is that the Chromium code (on Linux) is not yet doing stable code releases. Currently, I pull v8 and chromium code from SVN (and strip out all sorts of disgusting nonsense that is utterly and wholly unnecessary), then package it up, remerge my patches, build on three Fedora targets (F10, F11, F12), two architectures (i386|i586|i686 & x86_64), do some basic smoke testing to make sure that browsing works, and rsync the new packages to my fedorapeople.org space (along with repodata). This process takes about two days from beginning to end (most of the time is in builds, although remerging my patches usually takes a fair amount of time too). However, the point here is that everytime I build, I'm having to guess as to whether the code is in a workable state. There have been a few times where I've gone through the work to regenerate my patchset, built a set of packages, only to discover that some key functionality is broken at the moment, requiring either a later checkout or a bugfix from upstream. An open source project with stable releases marks a point in time release as reasonably stable, gives it a release number, pushes out tarballs of that source tree, and does patchfixes on that release for some period of time to cover things like severe bugfixes and security issues. Example, Firefox 3.5. Google isn't doing this yet, and I'm not sure when they will. (Note: I have asked various folks @ Google who work on Chromium about this, and only get vague wishy-washy maybe-sortof-coming-soonish answers. Keeping in mind that as of this writing, they are not officially even in "Beta" yet (understanding that the term "Beta" is really meaningless from a Google perspective *cough*gmail*cough*), I'm willing to be patient here.) Google needs to have "stable" releases before I would even think about maintaining it in Fedora.
But wait, you might say, there is a "stable" drop, the 3.* series. Yeah, except there is no bugfix plan, and most of the key features are either unimplemented or under-implemented in that release. Not much of an option.
* Google doesn't really treat v8 as an independent project. This is a shame, as the v8 code is pretty darned nifty, and it would be great to see it getting wider adoption outside of the browser space (or even outside of the "browsers-that-start-with-chrom" space). This is the power of leveraging cool code as an accelerator, working with other open source community projects. and gaining developers and users exponentially. How could Google do this? Well, for starters, see the above item, and replace "Chromium" with "v8". Define an API, and stick with it, at least for a major release version. (Need to make big changes? That's why unstable branches are for.) Stop bundling the v8 source as part of chromium, and document that you need to have version X.Y.Z installed to build chromium. ("Unpossible!", I hear the v8 devs crying out, except that I've been doing exactly that, for months.) But, you may ask, what is the big worry about a "stable" v8? Isn't a "stable" chromium code drop enough? Well, no. The problem is that the v8 development is pseudo-independent of the chromium code development, and the current bugfixing method for v8 (just like for chromium) is to update from SVN. Now, I've got two projects like trains, chugging along on separate train-tracks, and I'm clinging between them to keep them together. If one moves too fast (or two slow), I get pulled apart (figuratively only, I hope). The upstream rebuttal seems to be "This won't happen. Don't worry.", but I've been doing this FOSS stuff long enough to know better.
* Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct. What should happen is this:
[google] hey, it sure would be nice if we could use sqlite in chromium for our local db needs.
[google] hmm, the sqlite API doesn't mesh 100% with how I'd like chromium to use it
[google] hey sqlite upstream, there are a few places where we'd like to see API improvements so chromium can leverage it for our use-case
[sqlite_upstream] hey google, so cool that you want to use our code.
* sqlite_upstream looks at google's proposed changes to sqlite *
[sqlite_upstream] interesting, you could try using the foo_bar function for your camel launching needs, but the rest of the changes seem okay
* sqlite_upstream commits changes to the source tree in commit rev 12345 *
[sqlite_upstream] Our next release will support that.
[google] yay! we'll tell people to either apply our patch or use commit rev 12345 or newer.
To be fair, when Google forks an upstream project in chromium, they do write a README.chromium which summarizes the changes that they made. This is technically, better than nothing, but much in the same way that swimming in a pool full of angry, underfed, electric eels is better than nothing when you're desperate for a quick swim.
The rebuttal from the Chromium upstream is roughly this (although, not always in this order):
** We move too fast to work with upstreams in this manner. (Answer: No, you don't, and if you did, and you could document that, it would make a forking action more rational.)
** Chromium is too unique for this to work. (Answer: No, it isn't. Re: Tyler Durden in Fight Club.)
** We have people maintaining all of these forks and we always well, so its fine. (Answer: Really? Really? For how long? For this month, for this year, for ever-vers? What if everyone did that? We'd have thousands of forks of openssl, and possibly millions of forks of glibc.)
** We need special hacks for Windows/MacOSX/Linux that upstream probably wouldn't take. (Answer: Gee, I bet that they would like to properly support those platforms too.)
** Our hack is ugly. (Answer: Well, clean it up. Heck, even submit it as is, it might not be as ugly as you think, or upstream might help you come up with something that is prettier.)
** We need this for our pre-built magic binaries of Google Chrome (tm). (Answer: That's great, but I don't care what goats need to be sacrificed on what altars to make your magic binaries. If having hacked up copies of mystery third-party code-meat embedded in your "official" binaries is what you want to do, knock yourself out. I can think its dumb, risky, and long-term unmanageable, but its your code. Put a sweater on it and take it to the prom if it makes you happy. Heck, the nature of Windows might make it a fact of life for that platform, but if you're going to be dependent on pre-built upstream bits, wouldn't you prefer that those bits be supportable by that upstream, instead of forcing you to carry that support burden forever? Hint: The answer to that last question is yes.)
** We need this specific version for Chromium to work. (Answer: Lots of FOSS apps depend on specific versions of third party bits to work. Thats why those apps check for the existence of their dependencies on the system during initial configuration (pre-build), along with the specific versions of those deps. Heck, the pkgconfig infrastructure was built specifically to take some of the pain out of that procedure.)
** Chromium doesn't have an initial configuration process. (Answer: Well, gee. I wonder if that would be useful.)
** You just don't understand. Don't worry, we know what we're doing. (Answer: Uh huh. Okay. Where I grew up, when someone said "Don't worry, we know what we're doing", when there was ample and obvious evidence to the contrary, that person was usually about to blow off an appendage with fireworks. Forgive me if I take several large steps away from you now.)
Part of (okay, most of) my patchset has been to do exactly this, strip out Google's local copies of third-party upstream bits from Chromium and use the Fedora system copies. I've gotten a significant amount out, including bzip2, zlib, minizip, v8, icu, libxml, libxslt, and some of the mozilla bits. Some bits, like WebKit, are theoretically removable, but because Chromium depends on such bleeding edge WebKit code, are not practically removable, even though it is one instance where they have most of their changes in the upstream WebKit source.
To get Chromium into Fedora, I'm going to have to ask FESCo for an override of the guidelines involving bundled copies of system libs (specifically, that such behavior is not acceptable). The fewer examples of this in the Chromium code, the more likely that FESCo will permit that exception. I'm realistic enough to know that this will probably take a long time to drop to zero (yet, somehow, Mozilla manages it with Firefox), but hopeful that it will someday just be "WebKit because it is too new, and when WebKit catches up, not even that."
** Ubuntu doesn't care. (Answer: They should, and I bet, if you ask them, they probably do. But again, if someone else wants to do something dumb/dangerous, that doesn't make it a good idea. Note: I'm not implying that Ubuntu is dumb or dangerous. Insert any other distribution name there if it makes you feel better, I'm not trolling for an attack of the Ubuntu-fan boys/girls.)
* I haven't sat down and worked out all the licensing compatibility concerns yet. When I started doing that with any seriousness, I found a brand new (to me) license on the first piece of third party code that I found, and I'm not even sure if it is Free (waiting on the opinion of Red Hat Legal). The spaghetti nature of the relationship of Chromium and its third party code-bits makes determining the license of the meatloaf end-result somewhat mysterious. I've been assured that everything is kosher, but this comes from Google, who sees nothing wrong in redistributing all of the code to ffmpeg as part of Chromium. I am going to do this, just haven't had the time to beat through it all yet.
So, with all that, why do you even bother packaging Chromium for Fedora? Well, the application is interesting, and I think the competition in the Web Browser space for Firefox is healthy. It runs fast, and reasonably well, and has feature functionality that I like.
I do think that with great power comes great responsibility, and Google could truly be a much better community participant than it currently is.