Mistakes

I was a bit surprised recently when I read about Ubuntu’s PPAs. After years of being irritatingly good at everything infrastructure-y, this is a mistake so hilariously bad I don’t know how they could have made it. Basically, Ubuntu has institutionalised the third-party repository.

A PPA gives any registered Ubuntu developer a personal repository into which s/he can upload new packages for any supported Ubuntu release. These are built on a central buildsystem (which is good) but, crucially, they are *not built against each other* (which is very, very bad).

The key problem with third party repositories, as the Mandriva world learned extremely painfully between 2000 and 2004, is that they cause all sorts of interaction problems.

As Mandrake / Mandriva, until recently, had no real provision for doing significant package upgrades / changes for official releases, third party repositories naturally appeared to fill the need. These would include version upgrades, new software and other significantly changed packages compared to the official release. And because there’s a body of users who always want the latest shiny everything, they became very popular.

They also caused huge amounts of problems. As there’s some history here, I should be careful to note that in most cases, these were really not the fault of the third party packagers, exactly. The problems are with the whole setup.

The biggest problem comes with upgrades. Upgrading between releases of a Linux distribution is, as most people who’ve tried it know, a fairly dicey proposition in any case. Adding packages from third party repositories just almost inevitably made it break. The installer is built with the latest official packages in mind. I don’t know of anyone who installed something substantial from a third party Mandrake / Mandriva repository (except one specific one that has, well, special circumstances) who then got a trouble-free upgrade to the next Mandrake / Mandriva release. It just breaks stuff. Ubuntu has, by all accounts, been having increasing problems ensuring good upgrades with each release (although it’s something they started out being *very* good at). PPAs are just going to make that about five hundred times worse. I confidently predict that the number of people who have trouble upgrading from 7.10 to 8.04 will be far greater than any other upgrade in Ubuntu’s history, and a lot of them will be people who used PPAs.

The second biggest problem is that third party repositories do not play well together. I mentioned above that PPAs are built on a proper central buildsystem, which is good. This will at least avoid the problems caused by amateurish third party repositories that don’t understand the importance of a clean buildsystem and upload badly built packages. However, they are not built against each other, which is very bad. The classic problem with this scenario goes as follows. Package Foo depends on Package Bar. Packager Bob adds Package Bar to his PPA – he upgrades the version, makes some significant packaging change, whatever. Packager Jasmine adds Package Foo to her PPA. As Jasmine’s PPA is not built against Bob’s PPA, Jasmine’s Foo is built against the official Ubuntu Bar. But what if a user installs Bob’s Bar and then wants to install Jasmine’s Foo? Trainwreck, that’s what happens.

If you’re *lucky* they’ll explicitly conflict and Jasmine’s Foo will just fail to install. Then you’ve just got a minorly narked off user. What can also happen, though, is that there won’t be any explicit package conflict and Jasmine’s Foo will install perfectly happily…but it won’t quite work right. There’ll be some bad interaction that causes all sorts of odd buggy behaviour. The user will haul off to the Ubuntu forums and report this behaviour. “I can’t reproduce, it works fine for me,” some helpful person will say. Then another. They will suggest things for the user to try that will do nothing to resolve the problem. The user will get increasingly frustrated. *Finally*, someone will think to check what version of Bar the user is using, and the problem will be revealed. Or not – the user will just be stuck with the broken behaviour and never know why.

The fact that there’s literally hundreds of these PPAs, and their design is such that they’re *intended* to be small and virtually single-purpose, is going to make this massively more likely to be a big problem. There were only ever maybe 10-20 commonly used third party repositories for Mandrake / Mandriva and we had all sorts of trouble like this. With over 100 independent little repositories this has the potential to be a gigantic nightmare.

The last big problem is related to the previous one, and it’s this – third party repositories are a support *nightmare*. As noted in the example above, the only way to figure out what our poor notional user’s problem is, is to find out that they’re using a PPA Bar package. Now imagine *every* time you want to help *anyone* with *any* issue, you have to check what versions they have installed of all the packages related to the issue. Yep. If they have a problem in Epiphany – check their entire GTK+ stack. Check their Firefox package. Check all *sorts* of stuff. Do this every time. Forever. Learn, or look up, the entire dependency stack for any package anyone ever comes to you with a problem for.

The people who help others out in the Ubuntu forums are either doing their nut about the whole PPA thing right now, or they will be very soon, as they start to encounter problems like this. It makes it just incredibly hard to help people.

It only took Mandriva about six years to come up with a good answer to this problem. Fundamentally the solution is to have *one*, official repository for non-security, non-bugfix, major changes to packages in a released version, have the packages in that repository *build against each other*, and have a policy for what can go in it (i.e. no important libraries). This is the /backports system used since Mandriva 2007. Prior to that we had the ‘community’ tree for the 10.2 and 2006 releases, which fulfilled basically the same function but in a much less well organized way. You would have thought that other distributors would learn from our experience, but apparently not.

Of course, the fact that Ubuntu *also* has a backports system – which will apparently just roll alongside the PPAs – and a proliferation of true third party repositories (small repositories with random updated versions of applications, built and provided entirely outside the official Ubuntu framework) and random .debs being uploaded to project websites is only going to make the interactions that much more difficult to trace.

Part of me wants to sit back with a gigantic grin and a bag of popcorn and watch the carnage, but honestly, I feel sorry for the users, and also for the poor sods who do Ubuntu support.

2 Responses

  1. indianseason
    indianseason October 25, 2007 at 8:40 pm | | Reply

    Okay I had to create a login just to comment on this post!

    First off, I think you are doing a brilliant job promoting Mandriva around. I think your postings around the net led me to take the plunge and install the 2008 One version. (Given the volume of posting is it are there more than one of you behind that name??)

    I have been a long time Mandrake user and before that a Red Hat user (Redhat from around version 5.2 and Mandrake since around version 8 or 9). Version 9.2 incidentally is still running happily on my father-in-law’s pc. In 2004 I switched to pclinuxos as I had terrible problems with 10.1.

    One thing that has riled me during this time has been the tendency of debian (and ubuntu) users of making disparaging comments about rpm’s dependency hell. A lot of that was because of third party rpm sources. Dependency issues have been as (ir)relevant to the rpm world since urpmi and similar tools came along.

    Finally with this ubuntu step perhaps the rpm guys can have their revenge with the deb guys on the dependency hell. Not that I am wishing anyone ill, by the way.

  2. adamw
    adamw October 26, 2007 at 7:16 am | | Reply

    “Given the volume of posting is it are there more than one of you behind that name??”

    nope, it’s all just me :)

    yes, indeed, one point I was going to make but cut for length was the same one you mention: the second generation of ‘RPM hell’ complaints almost always related to third party repos. Good point.

You can comment without reCAPTCHA by using an OpenID as the URL, or logging in with an OpenID or an old site account.

Leave a Reply