Do we really need another packaging system?

Recently I've been quoted by Steven J. Vaughan-Nichols for questioning the need for the LSB Package API. The kind of conversation going on over the LSB Package API has been a recurring theme ever since I started using Linux, and it contains quite a few fallacies I would like to put down. Most importantly, the most common theme I've heard is that this fancy new system could usher in a new era of easy package installation for users. Let's go over some of these myths.

MYTH: PackageKit is just one level of abstraction on top of package management that serves no purpose other than to make things more complex.

REALITY: As stated in said article, Linspire has also created such a layer. There is a huge difference between PK and CNR though. CNR is really more of a user based shopping center for packages that traditionally wrapped on top of Apt. I haven't looked at it at all in the past year, so I am not fully qualified to comment, but it seem to maintain that overall approach from what I've seen.

PackageKit integrates tightly with the Gnome and KDE desktops using some cross platform tools to make managing a system easier. Namely, PackageKit integrates with ConsoleKit and PolicyKit to let administrators fine tune the users control over packages installation. It is a far better solution than giving users access to sudo.

Neither of these layers are redundant. They provide a level of service well beyond what a basic package manager can provide. Furthermore, they provide it in a clear cross desktop and cross distribution fashion. The need for these two tools is clear.

MYTH: There are too many package managers, and the landscape is threatening, and unhealthy for the Linux future.

REALITY: Package managers are developed all the time, because every user needs something different. For the desktop user, package management all looks the same, but this is not true. For the enterprise user, package management is a crucial feature. For the enterprise desktop, being able to mix both these use cases is an optimal solution. Let's examine each one. In this case, we're concerned only with dependency resolution, because the rest is mainly a usability layer on top.

The first reality is that not all package managers do dependency resolution the same, because that's the key point of a package manager. For example, there are a number of dependency cases that only a handful of package managers can solve correctly, such as the libBCD use case. The last time I checked, both apt and yum fail to solve it, but zypper has no problem with it. Even if the user doesn't care, having bad dependency resolution on the desktop can make life difficult for new users as well as advanced power users. openSuSE had the drive to innovate package management a little bit, and it's paid off by having a quality dependency resolution.

Other distributions, such as Gentoo and Crux take two totally different approaches. Admittedly neither of them are intended for the average desktop user, the idea of dependency resolution on both those distros is entirely unique.

In the enterprise, a package manager is not just a tool for delivering software once to a system, but a tool for creating bits of a system out of a variety of components. Deploying server applications, such as java applications can require an incredibly complicated and thorny dependency resolution process. It can include a number of criteria, such as prefered way of deploying java packages (there's about 15 different ways to do it), deploying custom kernels based on hardware, intended work load, configuration of the day, or one-shot actions such as updating the bios or other firmware. It could include other external matters, such as deploying language files for a certain region, because a laptop has been transfered from one department to another as part of an enterprise reorganization. This is overkill for the desktop user, and it is critical that there be more than one package manager in the Linux landscape for this reason alone.

(One of the values of yum is its plugin system. An enterprise administrator can develop all these plugins using the same package manager that normally fits on the desktop.)

Having PackageKit subject to this complex dependency resolution process is good for the enterprise desktop. Certain 'power users' in a company can be given permission to install extra packages from trusted company sources as is needed. Even updates can be handled by the user. To an administrator, this situation is ideal, because he receives two guarantees. 1) the user is getting the right packages, and that the system will likely not break down. 2) the user is empowered to do their job and is a satisfied coworker.

Thus, the conclusion so far is that PackageKit and multiple package managers are a clear necessity to the Linux Community.

MYTH: There are too many packaging formats, some are too archaic. Why can't we just settle on one format for writing packages?

REALITY: The LSB Packaging API uses XML. For that reason alone, there will be at least two packaging formats. Not all of us like XML. Nor is XML the ideal format for delivering package information to every system. For the reasons I stated above, different formats are needed for all the different use cases. A Crux pkgbuild or a Gentoo ebuild is a packaging format fine tuned to the systems they run on. Forcing them to use some other method to package their programs wouldn't make any sense at all.

In the article, the author writes:

Hell, if you really think scripting is the best way to install
software in 2008, why not go back to installing everything by
compiling all software from source code? That works even better
and it will work on any Linux distribution. It’s tedious and
requires every Linux user to also be at least enough of a
developer to be able to deal with gcc, make, and library
compatibility issues, but hey it would work.


This seems to imply that there is something old fashioned in using shell scripts. This couldn't be further from the truth. In creating nearly all packages, there is always some amount of shell scripting that needs to be done. Many packages require some form of post-install and pre-uninstall scripting to be done. The most universal method for doing this on any distribution is a script. The best part of this though, is that it works entirely behind the scenes. I never have to interact with RPM running any script, as the process is completely hidden from the end user. Putting a layer in C on top if this only makes the life of a package maintainer harder.

MYTH: We should have some system of universal packages. The user should be able to get a package from just about anywhere, and it should run automatically on their Linux system.

REALITY: I am not going to go into the MSI installer debate that has been argued to death. Let's address some of the real issues that face the Linux desktop.

Every distribution uses slightly different compiler settings. There are a million and one reasons for doing so, but in effect, no package, neither RPM nor DEB, nor anything else is guaranteed to run on every Linux system. Having some universal package API will not solve that problem, and will only draw users away from the real target they should be focusing on.

Third party software that hasn't been developed with your distro in mind presents a strong problem for everyone. Chances are, it will break your system. Having a common API will not make the problem easier, because there are always a number of other layers to worry about. For example, if the program doesn't ship with an SELinux policy, it will break for all confined users. Using something like the SuSE build service to get the latest Amarok for Fedora would be pointless. Your distro may use an alternate file naming scheme, such as GoboLinux. RPMs would have a hard time working in such a system, let alone some random API.

The reality of the situation is that the differences between distros gives people a chance to innovate more with how a Linux system works. Trying to funnel everything down through some common layer at the bottom really reduces the chances for big innovation to happen. Steven comments that layers like PackageKit and CNR are bandaids on top of a failed process. This is not how I would describe it. They are tools to make the confusing landscape easier for the end user, while letting distributions maintain their competitive advantage. I highly doubt that such a common API will be effective, let alone accepted easily by the community.

But please, prove me wrong.

Making Communication Easier

One hot topic that was discussed alot were a few of the communications issues the French team is having. I have a nice long laundry list of some things they would like to see changed or that can be done better.

The number one complaint was a lack of history on the Fedora Planet blog. Reading through English posts can be time consuming, so it's quite common for people here to push that off to a once a week event. Since most articles disappear after two to three days, most articles are missed. I cannot stress enough that I heard this complaint *alot*.

On a more positive note, several people told me how happy they were to hear about gregdek's translation bot and would love to see this put into production use. Let's hope it doesn't turn into a bikeshed issue on how to integrate it with our regular channels.

The rest of the issues centered around making Fedora Planet more accessible. There was one proposal to make it a requirement to provide at least a one sentence summary in English with each blog post. Another proposal was to provide automatic 'translate this post' links for every single post. Optimally, this could be available in the RSS feed too. (One person mentioned that he doesn't see the translate links in Paul Frield's posts.)

One final proposal was to turn it into something approximating a full web application, where the user could access the stream through any number of filters. Some of these filters could be 'french blog posts only', or 'all posts, but through a translator', and a few others. I suppose this would take more work to implement, though.

Some of the things the Fedora FR team has done

Over the weekend, I spoke to alot of people in the Fedora FR team about some of the things they've done. So far I've had only an small inkling of the amount of work they've put into promoting Fedora. I think that it's time that the rest of the world knows what they've been up to.

The Fedora-FR group and non profit organisation is concerned with promoting Fedora within the Francophone community. This includes not only France but southern Belgium, some border towns in Germany, northern Africa, half of Switzerland, and any other community that speaks primarily French. As I've written before, the Fedora FR team is on the unique challenge of providing Fedora as a good resource to a population that does not speak English well.

In a nutshell, they've reproduced most of the information infrastructure available to the mainstream Fedora but in French. They have their own:


The Organisation is made up of:
  • 19 Ambassadors
  • A whopping 14,600 people signed up to the forum
  • 80 documentation writers
  • 22 contributors to the French blog.


They've put together in the past:
  • Powered by Fedora stickers
  • Fedora pins - I have a few, the quality is excellent
  • A French Live CD spin
  • An Online Fedora Schwag store - Including the unofficial Fedora thong.
  • A PDF Manual for Fedora available for offline reading
  • Articles in local magazines


They've arranged and ran many events for the French Community including at least 3 install fests for every Fedora release. Overall, they are sincerely one of our best and top performing marketing and Ambassador teams in the Fedora world.

This presents a few issues in regards to Fedora as a whole. Firstly, there is a strong overlap between the efforts of Fedora FR and Fedora EMEA. They are both looking to provide an outlet for alot of Fedora resources, including funding of events and running online stores. Even so, the focus of Fedora EMEA is far more corporate than Fedora FR. Most of the members of Fedora EMEA either use Fedora professionally at work, or work for Red Hat. In contrast, Fedora FR is made up mostly of community members who use Fedora for fun. The bar for membership is alot lower in Fedora FR, and they actively encourage people who participate at events to sign up for membership. One thing that we certainly can work on though is better communication and collaboration between Fedora FR and Fedora EMEA.

My weekend in Paris has been quite enjoyable so far. I can certainly say, without a doubt, that everyone in the French speaking Fedora community is quite hospitable, and more than happy to welcome visitors. If you can speak French, I really highly recommend visiting this community. It is definitely a very valuable experience. I would like to thank the entire community for hosting me this past weekend.

What are the best kinds of Fedora users?

Today I gave a presentation with the help of Thomas about the different kinds of Fedora users. I gave the presentation in English, and Thomas translated it on the fly into French. Although my French skills are poor, the parts I did understand seem to express what I was saying. I thank Thomas for helping out.

The presentation itself was mostly a ripoff of a previous presentation I found on the wiki with a few touches of my own. It can be found here (Impress) and here (Evince). I apologize, but the Impress version needs the fonts Copperplate and Calibri to be displayed properly. If you want to use this presentation as your own, please feel free. I ordered the slides to be provokers of discussion, rather than pure factual information.

The trend seems to be pretty simple. Users show up in the Linux world as just users, and progress through various stages of being a power user before they become a contributor of some kind. One of the common speaking points on the American side of the pond is that in some ways we need to encourage all our users to be more than just users. If anything, we want there to be as few barriers to new contributions, in order to encourage this process.

One of the slides in particular is a favourite of mine. It's a set of various 'ideas' that led to the development of some of the more heroic efforts in Fedora. This includes projects like Revisor, Func, and even the Bug Triaging team. They were all started by individuals both inside and outside of Red Hat who simply stood up and got to work. This was the point I hoped to get across. (The people behind these projects, you know who you are, so feel free to stand up and take a bow, even though no one is watching.)

I hope that this approach can also be useful to the French speaking Fedora team. There is a strong language barrier between the French group and the rest of the Fedora world, and because of this, the attitude here is pretty insular. I spoke with alot of people here about it, and I have some definite things to work on to help bridge the gap, but I also want to make sure that this message is available to the French speakers in French. There is a strong and fast developing user base in France thanks to the efforts of all the French Ambassadors. Hopefully my presentation and material can be incorporated into the French team's work as well.

Paris - The City of Install Fests

I've made it safely to Paris for the Install Fest this weekend, and I don't understand a single word of what's going on. Last night, we went to the Restaurant de Flammenkuechen. There, we had a meeting of all the associated Linux geeks and nerds in the Greater Paris area, over many many plates of Flammenkuechen. The Flammenkuechen, despite it's German name, is a pizza-like dish from the Alsace, which can be an entire meal. It's essentially a thin crust smothered in all manners of pungent french cheeses and topped with bits of mushrooms, ham, peppers, tomatoes and anything else handy. For desert, it's more flammenkuechen complete with chocolate or apples and cinnamon, all served with many glasses of white and rose wines. I can't say that I really followed most of the conversations at the table, but I did get a chance to get to know some of the members of the community there. The Linux community in Paris, and in France overall is incredibly active, judging by the noise in the room alone.

I was fortunate to be there during the night of La Fete de Musique, which is a huge Europe wide festival in many different cities, where it it is legal for anyone to just start performing on the street or in a club free of charge. Judging by some of the neighborhoods we walked through, France also has an incredibly vivid gay community. We spent most of the night wandering through Paris sampling all the different music all over.

Getting back to my host's house was a bit of an adventure. Normally, the Paris Metro is closed from 1 - 6 in the morning. For the music festival, it was up and running, about as well as New York City. The entire Metro system, for those who don't know has been built mainly in the swiss cheese holes that formed underneath Paris some many thousand years ago. Travelling around normally is next to impossible. Getting around at 3 in the morning is worse. After riding for about 20 minutes on one very very crowded and overheated train, we found out that we had to wait about an hour for the next train. After debating if it would be worth it to walk an hour and half home instead of waiting, we decided to at least pop our heads outside where it's a bit cooler and see how far it really is. Paris also has a reputation for having really expensive taxis. On a whim, we decided to ask a passing taxi driver how much it would cost to get a ride for the final leg home. Expecting it to be about 50 euros, we were pleasantly surprised to find out that it was under 10 euros. If there's one good thing to say about the public transportation in Paris, it is that the taxi drivers are friendly and fast.

This morning, after slowly getting up, going for another hour long joyride through the Metro, I sat down with the leaders and members of the Fedora FR non-profit organisation and had a talk to them about some of their goals and what they've done so far. I think I'll put this in a blog post later.

Some Pictures.

Transavia is clearly geek friendly.


I love localized technology.


Amazing food.


The geek club where the Install Fest is being held. One Euro Coffee is certainly a geek's friend.


Selling Fedora Ambassador polo shirts.


One very happy customer. (With one very happy future Fedora user to-be inside.)


By the end of the day, these will be running Fedora 9 too!

He's a traveling man

I"m on my way to Paris, and I have to say any airport that serves up free wifi definitely gets an extra special award from me. Today's featured airport is the Rotterdam Luchthaven, in Rotterdam of course. Going through this airport is about as easy as Pittsburgh. It's quiet, tastefully decorated, and going through security and check in takes about five minutes total. Of course this may have something to do with it being a Saturday, and that there is very little traffic.

I can see a prop plane in the distance, I hope it's mine. It should be alot of fun.

Now if only the US could learn the fine art of offering air flights for eight dollars, plus ten times that in taxes.

The Best and the Worst

There are some good parts and bad parts about basing yourself out of the Dutch country side.

  • There are virtually no distractions, good for getting work done
  • The air and water are much cleaner than Pittsburgh
  • The people are relaxed and genuinely friendly
  • You can leave your groceries with your bike while you step into the pub to have a drink or five
  • It's normal to drink 6 beers during a football game
  • You can go biking in the Nude


The Bad

  • The train station is 20 minutes away by bike, when the buses are on strike.
  • The train station is 20 minutes away by bus, when the strike is over.
  • The train station is 35 minutes away when you don't bike like a crazy American.
  • There is a crackhouse next to the train station. It's not a good idea to leave your bike there over night.
  • There is no Foreign Police office in town, thus requiring a trip to said train station.
  • Getting to the office in Amersfoort requires a bike marathon.


The Ugly
  • Sometimes you wake up, and the town smells like sheep. It's so strong that the smell can reach Arnhem

Review Request

Pertaining to my previous blog post, i have some packages that need reviewing.

Anyone want to review the following?

https://bugzilla.redhat.com/show_bug.cgi?id=451768
https://bugzilla.redhat.com/show_bug.cgi?id=451769
https://bugzilla.redhat.com/show_bug.cgi?id=451771
https://bugzilla.redhat.com/show_bug.cgi?id=451772
https://bugzilla.redhat.com/show_bug.cgi?id=451773

Announcing the NetBookDora Project

What went from scratching an itch to finishing what I started, I would like to announce the formation of the NetBookDora sub project. The goal is to produce a respin of Fedora with a desktop well suited to the needs of Netbook and other sub-10-inch laptop users.

Recently, Canonical introduced its own foray into the world of mobile user computing with a set of tools for the Gnome Desktop. Canonical, however, denied any desire to release a generic respin of the Ubuntu desktop with these tools. Instead, this was left for the community to handle.

Currently, these components have been packaged for Fedora, and are available in a repository for download and testing. The next step is to get them included into Fedora as standard packages.

There is still alot of work that needs to be done to make this an official respin shipped with Fedora 10. Most importantly, there is a need for some art and graphic design. Currently, these packages ship with Ubuntu specific artwork. The current code for this project is set up as a Git repository to make sending patches easier. The only technical skill needed is some basic experience with Git.

For more information about the project, testing, development, or wanting to know how to help out, check out the trac instance. If you want to speak to me to help, I'm in #fedora-admin on freenode, and my email address is available through the Fedora Account System. You can also leave your email address in a comment to this post.

This really should be a reflex, not something to brag about

Why Trains are Better than Planes

This weekend I went "home", in a manner of speaking, to Regensburg in Southern Germany, where I lived for a year. When you live anywhere and make really good friends with the people there, it doesn't matter how long you stay, it becomes a home. But that's neither here nor there, since it has nothing to do with Die Bahn, the German train system. What's important is that it's quite easy to get to and from Regensburg via the DB, as well as bring back some souvenirs.


This ain't no ordinary laptop bag.


Try getting this through airport security.


These are just some of my most highly recommended beers. They are (from left to right):

  • Kneitinger Bock - "Nur echt mit dem Bock"
  • Weltenburger Asam Bock - Usually one of the strongest beers available year round in any supermarket
  • Bischofshof Kellerbier - so easy to open, yet so tasty
  • Weltenburger Barock Hell - A Baroque Hell is usually where you end up the next morning
  • Kneitinger Edel-Pils - A "Mas", a one liter mug, full of this beer is probably the best thing to have in September sitting around a beer garden.
  • Schlenkerla Rauchbier - Complete with it's own dialectal features, and a flavour that has to be tasted to be believed.

It's true

The coffee in Raleigh really does suck. The Munich office on the other hand has some pretty good coffee. This is to be expected, as Germany's biggest export is coffee.

I can has Netbook too?

Today was a relatively quiet day, as the amazing German train system seems to be one of the quietest trains I've been on. I'm sitting in Munich now, thinking about how Ubuntu is releasing yet another respin, this time focused around the so called "Netbook" market. Fortunately or unfortunately, I had the luck to come across this little number here.

For those of you too lazy to click through that link, in summary, Ubuntu is making a new version designed around the small screen, complete with binary blobs and support for all sorts of nasty proprietary things like flash and mp3 out of the box. The worst part is that there will be no upstream for this project. (When will they learn?)

I was curious, (and thanks to the limit of terms of my self inflicted Ubuntu/Debian ban,) so I decided to see how easily these tools can be built for Fedora. We have the respin technology, why not use it?



The whole build process went quickly, although with some difficulties. There are apparently a few odd key dependencies to Maximus, the window manager-ish thing Canonical has hammered together.



We also need to fix up some of the artwork a bit, so it's not so Poobuntu centric.



The next step is to make some RPMs for other people to try out, and possibly a temporary git repo for people to submit patches to.

Here's a list of the things we need to do to use these packages in a "Small Screen" spin.

  • Package them

  • Review them - most of the dependencies are already in Fedora

  • Create artwork maybe a slightly modified theme

  • Spin it

  • Distribute a slightly customized Gnome desktop on the spin



I can't say that I'll have the time to see through all these steps, but if anyone's interested, I'd be more than happy to start making RPMs.

Hup Holland!

So Holland won their first match in the European Championship, which was against Italy. This is apparently amazing because until now Italy was recognized as one of the best European teams in the world. This is interesting not because Italy was defeated, but by the extreme nationalism portrayed by the Dutch.

Speaking of which, I'm going to Germany tomorrow to visit the Munich office and meet the nice folks there. I've been convinced to carry all the Holland crap I can find, which at this point is an orange balloon that says 'Hup Holland', that I can stick in one of the outside side pockets of my backpack. If anyone around her had klompen (clogs) I could wear those too.

To Arnhem and Back

In order to go to Munich next week, I had to get myself reservations on the super fast and sexy German Intercity Express trains. As it turns out, they can't be issued at the Ede-Wageningen station near where I live. After biking 8km (5m) there, I was told that I had to hop on the next train, but it only takes about ten minutes.

One of the funny things about the Netherlands is how small the towns are. In order to get to the train station, I had to pass through two other villages just to get there. In between it's nothing but pictureque Dutch farmhouses by the sides of the roads. Then it's off to Arnhem for a grand total of 30 minutes, to get the reservations and head back. While I'm sure it would have been nice to wander around Arnhem too, I really wanted to head home and get some other things done.

All in all, I really didn't go any further than travelling from one side of Pittsburgh to the other.

Koji's build system is excellent

For all the bitching I did about Koji yesterday, one thing is certain. The build system works really well. After finally getting Koji setup after two days of frustration, I decided to try repeating my work with the development version. Getting the dev version built and setup, worked so well, I had to double check it about 15 times, just to be sure.

Your shipment of fail is here

Today, I got the following comment on one of my posts.

"Interesting .. your blog came as the second result when i Googled for "Fedora 9 a failure ? " ..
you forgot to mention about the "PackageIt" that hangs indefinitely , and the removal of the auto-login feature. Shame!, they removed beryl too :(, that was the saving face of F8 in my opinion wrt graphics."

Fortunately, this bug is not reproducible, but it did bring this to mind:



Don't worry Fedora. We still love you.

Marketing Blah Blah Blah

As I've previously announced, I'm going to be concentrating my energy on getting people to sign the CLA. In order to do that, I've come up with some specific posters to that goal. I want to get this set up for the Install Fest in Paris, so they also need to be localized. Any comments on the copy are good. I've never realized how hard it is to write for posters until now.







My only concern is that this might dilute the branding of the original posters. In any case, I plan on keeping these small, and specific to whichever table I'm working at. My plan for the install fest is to park myself down, setup the laptop, and then talk to people about how they can contribute back to the community.

EDIT: Not to be forgetting about the source code, it can be found here

The Truth about Truth

I arrived in Holland last night pretty late, and so far i've been keeping a low internet presence just getting myself moved in. Tomorrow I should be back in full force doing Fedora related hacking.

As I promised, I said I would explain what I meant by 'Truth Happens'. The truth is that a community oriented model of development with a strong emphasis on letting the community decide what to do with itself is a far more effective model for not only development but also marketing. Fedora had a very clear and strong presence at LinuxTag, and everyone I spoke to understood this. The fun part is that this entire effort was engineered by the community. From Fedora bathrobes to the unavoidable digs about being the 'Blue Man Group', it's easy to see that we are making a good impression in Europe.

The best part, though, is the response I got from SuSE and Novell. As some of you may already know, openSuSE is going to ship Smolt with the 11.0 release and enable it in the installer in the 11.1 version. On Saturday, I headed up to the SuSE room to have a chat with one of the managers to find out how well it was working for them. One thing I wanted to find out about was if they wanted to send any patches. Before I even got a chance to ask, Klaas Freitag asked me right out if we would accept patches. I was astonished. After Fosdem, Mike and I had a nailbiting couple of months wondering if they would just take our work and run away with it. Here I was being asked by a competing organisation if we could just collaberate instead.

It's starting to seem that openSuSE is understanding the idea behind a community effort. Perhaps they understood it 2 years ago and waited to see if we could succeed, or perhaps they just figured it out. I don't know. What I do know though, is that seeing how we've succeeded, they are willing to do the same.

There were also a number of other things that were discussed between several different people on both sides of the fence. I'm going to let them talk about it more, but it seems Smolt is not the only project we will have in common in the future. It feels good to be proven right.