Launchpad and the Future of Package Management

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

In his piece announcing Drizzle, MySQL’s Brian Aker had the following to say about Canonical’s Launchpad platform, saying:

Launchpad has turned out to be pretty awesome. You should be thinking about using it. Do not get caught up in the git vs bzr vs hg debate. It is not about the tool, think iPod/iTunes. It is about the infrastructure around it.

Which was appropriate, as the project itself was being hosted there. High profile though Drizzle may be, however, its choice of infrastructure by itself would not be that noteworthy except for the fact that it’s one of a number of projects doing the same.

Just on my own installation of Ubuntu, I’m using Launchpad builds of the following:

  1. Banshee
  2. Emacs
  3. Gloss
  4. Google Gadgets
  5. GNOME Do
  6. IOTop
  7. JSON-Glib
  8. Stackswitch
  9. Tasque
  10. Thinkpad Fan Control
  11. Thinkpad X300 Audio

Notice that these are not Canonical projects, but third party efforts. Notice too that they have little to nothing in common. And yet all are hosted on and served to me via Launchpad. In the past, these would have been hosted at repositories outside the Ubuntu ecosystem; the developer’s own site, perhaps, or maybe Sourceforge. Now, however, the trending is towards hosting over at Launchpad.

The reasons for this vary, and Ubuntu is far from the only distribution seeing this type of activity: Gentoo’s overlays have become the norm rather than the exception they were when I was running that distro full time.

What this points to, I think, besides an increased willingness to fork cited by Brian at OSCON and that I’ll talk about later, is the next evolution of Linux package management systems.

Package management, a subject I’ve discussed many times before, is magic in the Arthur C Clarke sense of the word as opposed to, oh, the Harry Potter. The first time you see it, you’re likely to be shocked because none of the commercially available operating systems today have an equivalent. Tim Bray’s reaction, in fact, is unprintable in this family friendly space, so positive was he on apt. And yet the differentiation package management permits is massively underleveraged. Here’s how I put it in March of 2007:

Despite this seemingly impressive feature, you’ll rarely if ever hear this touted by Linux advocates; perhaps they simply take it for granted given that many if not most Linux admins have never known a distro without it. As a result, my recommendations that Linux distributions press their advantage in this area by leveraging existing infrastructures to connect to both commercial and community oriented repositories more or less fell on deaf ears.

To be sure, Launchpad isn’t the solution to the inexplicable lack of attention paid to package management. But what it can do is evolve the feature to incorporate more third party applications, whether they’re built by Joe Developer or Google.

Which makes it worth watching, IMO.


  1. I gotta say, I don’t understand the iPod analogy.

    I mean, when I got an iPod, there was no iTunes store, there was no Windows support, and there were no “apps” for it. Soooo, yeah, why does the infrastructure matter?

  2. Maybe I’m misunderstanding your point, but a lot of what you are saying is misleading or just plain wrong.

    Most of the projects you’ve listed are *not* hosted on Launchpad. They are mirrored there, and Ubuntu-specific packages are created there. From a typical user point of view, this is entirely the same as the openSUSE build service and other traditional distro repository channels.

    The difference with Launchpad is that it *does* make distributed development of these projects a lot easier. However, in most cases, it is still an unofficial mirror, and upstream developers for the most part do not keep track of what happens on Launchpad. They wait for patches to be submitted in bug reports or mailing list posts.

    So, while Launchpad is pretty cool, and the Ubuntu community gains a lot from it, from the upstream point of view it is yet another place where downstream development is splintered off. This is especially noticeable with bug reports, since in reality not a lot of development happens in the Launchpad branches. Luckily, Canonical is aware of the issues and very interested in adding more useful integration with upstream bug trackers.

    There will never come a day where every free software project is primarily hosted on Launchpad, so it’s unrealistic to imagine it as the upstream for everything that matters on your Linux system.

  3. @Sandy: apologies for the lack of clarity. the intent was to focus on the availability from a user perspective, not to imply that most let alone every project would be primarily hosted at Launchpad. as you say, that’s unrealistic and should not be the expectation.

    that said, i have seen a number of projects – projects like Awn – make the transition from external hosting to Launchpad for some of the reasons you mention and others.

    the real point here is that there are an escalating number of projects available at Launchpad – whether that’s the primary or secondary host – and that that simultaneously simplifies and extends the user package management experience.

    Launchpad PPA’s are now my first choice as an overlay, rather than an unusual exception. i have no expectation that all software will be available there, but there’s an awful lot more than there used to be. which is good for me, probably good for the developers, and certainly good for Ubuntu.

  4. @Danno
    I think Brian’s point is that the bzr/git/hg is a debate about a single tool. It’s reminiscent of vim versus emacs. But for developers there are other additional requirements to optimise the workflow. That’s where Launchpad comes in as it provides other resources that a project needs making the whole thing more complete. So if you’re interested in these other areas then the ipod/itunes analogy fits.

  5. […] it funny that I couldn’t pay vendors to talk to me about pressing this advantage. Piece after piece after piece after piece was met by crickets. Till even I more or less stopped talking about […]

  6. […] Brian discussed at OSCON back in 2008, all of a sudden forks become trivial; both to execute, and potentially to reintegrate. On Github, […]

Leave a Reply

Your email address will not be published. Required fields are marked *