Making Projects Easier to Package: Why Chromium Isn't in Fedora

by Joe Brockmeier - Dec. 02, 2009Comments (2)

Some projects make it easy for Linux distros to package their software, others not so much. Google Chrome, or rather its Chromium project, is one of those projects that is emphatically not easy for Linux distros to re-package and ship. Tom Callaway of the Fedora project explained this week why he's packaging Chromium for Fedora users, but not as an official Fedora package. The rationale is interesting in the specific instance of Google Chromium, but also a good lesson for other projects and companies that are doing open source development.

Callaway points out several problems with Chromium being packaged for Fedora, some that are just the nature of a fast-moving project like Chromium. Since Chromium isn't releasing "stable" builds for Linux yet, though many of the releases work just fine, it's not in a state yet to break off a chunk and make it part of an official release. That's not particularly bad, but Callaway says that another problem with packaging Chromium for Fedora is the way that Chromium makes use of upstream libraries:

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.

He then goes on to deal with some of the rationalizations for not syncing better with upstream projects. In short, there's a lot of room for improvement. But, again, this isn't just a knock on Chromium -- it's also a good read for any project that wants to be packaged by distros. Having to ship a separate copy of libraries for a specific project like Chromium is not a particularly clean solution for distributions, and typically goes against the packaging guidelines.

Note that Google also releases builds of Chrome for Linux distros as well. Users of Ubuntu, Fedora, openSUSE, and Mandriva can find repositories on the Linux repositories page. However, this represents an additional step for users, and it'd be very beneficial for users to be able to get stable releases of Chrome from their primary distribution sources.

Joe 'Zonker' Brockmeier is a longtime FOSS advocate, and currently works for Novell as the community manager for openSUSE. Prior to joining Novell, Brockmeier worked as a technology journalist covering the open source beat for a number of publications, including Linux Magazine, Linux Weekly News,,, IBM developerWorks, and many others.

Jobin John uses OStatic to support Open Source, ask and answer questions and stay informed. What about you?


Would this problem exist if there was only one package format for all the Distros? To be more specific if Red Hat and Debian were to just agree on only using rpms or deb for every single linux distro or create a whole new package format and declare that the linux package standard would this problem exist? If so why?

0 Votes
Share Your Comments

If you are a member, to have your comment attributed to you. If you are not yet a member, Join OStatic and help the Open Source community by sharing your thoughts, answering user questions and providing reviews and alternatives for projects.