Package handling in anaconda – another retrospective

So there’s a thing that’s come up a couple of times about the new package selection UI:

“PLEASE reconsider not giving us the ability to select packages in the installer!”

Here’s the short answer: really, there’s better ways for you to do this. Try using the nice packaging tools that come with the system once it’s installed! Or, if for some reason you absolutely cannot modify the system after it’s installed, you can just use a Kickstart script!

More importantly, though, it’s a huge amount of time and effort for us to maintain a totally separate packaging GUI in the installer, and we’re pretty well convinced that individual package selection inside the installer isn’t worth the pain.

Oh yes. The pain.

In the Old Days of Red Hat Linux and Fedora Core, the installer had its own custom package selection GUI and package handling library. Which should be obvious – anaconda was written before yum existed.

But this meant the anaconda team had to maintain a totally separate packaging stack, with its own depsolver and a totally different UI that was inconsistent with the rest of the system.

It wasn’t good code either. Here’s a sampling of comments from anaconda-10.2.1.5 in Fedora Core 4:

# ugly hack
# hack hack hackity hack
# hack to make everything and minimal act right
# XXX This is surely broken
# XXX hack but will work for now
# XXX: large hack lies here
# FIXME: I BROKE IT
# FIXME: surely this can be made faster/less complicated
# FIXME: this is a bad bad bad hack.  we should probably tag
# FIXME: this is a major hack to get the comps package installed
# FIXME: this is a huge gross hack.  hard coded list of files
# FIXME: oh dear is this a hack beyond my wildest imagination.

There’s hundreds and hundreds of lines like this, all over the installer – but especially in the packaging bits. It was an enormous, painful mess.

A New Hope

Finally, sometime in 2005, the decision was made to make anaconda use yum. At the same time, we decided to write a new version of the anaconda package selection GUI, but write it so it could be used in the installer and in the normal system. Shared code means less work, right? Hooray!

And so pirut was born, and after many months of work, in April 2006 it became the new package manager in Fedora Core 5.

It was not a resounding success.

People were not very fond of pirut, or its system update notifier, pup.

And it actually made a lot more work for the anaconda team: they were still responsible for the installer, and its (brand-new and not-very-stable) packaging GUI, but they were also responsible for the packaging and update tools used by the entire rest of the system.

It quickly became pretty clear that the situation wasn’t sustainable. Richard Hughes laid out the case pretty well in a blog post, provocatively titled Installing and Updating Software Blows Goats. That was July 2007; over the course of the next year he designed and wrote PackageKit, which replaced pup and pirut in Fedora 9.

I won’t claim that PackageKit was (or is) perfect, but even reviews that called it out as a problem said things like “PackageKit is also a marked improvement over Pup”; by Fedora 10 the reviews said things like “PackageKit has improved a lot and it does feel better than the previous pirut and pup software.” And things have only gotten better since then. (Seriously. Go back and try out Fedora Core 5, or Fedora 10 if you don’t believe me.)

The world has turned and left us here

Where did that leave the anaconda team? Well, since pirut was anaconda’s package selection UI, we ended up having to maintain it ourselves. When the package was removed from Fedora in F10, all the relevant code had to be pulled into anaconda.

And so we end up back where we started: the installer had its own custom package management code and package selection GUI. And we had to maintain a totally separate packaging stack, with its own depsolver and UI. Again.

This screen, from the F17 installer?

Yep, that’s pirut. The same slow, ugly, clunky “heap of horseshit” that everyone hated in Fedora Core 5, now with seven years of hacks heaped on top.

Why are we doing this, again?

If it surprises you to learn that one of the goals of the UI redesign was to revamp the package selection UI, you are either really bad at reading or really good at being surprised.

So, just like everything else in the UI, we talked to a lot of people about how they used the existing UI, made mockups, got feedback, and so on.

And here’s what we learned:

1. Lots of people just don’t care

   For example: the Live images are super-popular, and they don’t have any way to choose extra packages during the install. Many people just seemed to want the install to happen quickly and painlessly.

2. Most were happier installing stuff from a running system

   Most people want to be able to look up details about packages before they install – things like “Is this game any fun?” and “What do I need to make my printer work?”. This is much easier if you’re on a running system, so they were much happier doing it after the install finished – and the tools are nicer there anyway.

3. Many wanted to be able to select Spins or Add-ons

   For these people it wasn’t about picking specific packages, but making sure you could pick a base like “KDE” or “GNOME” (or “Minimal”, which came up a lot) and add stuff on top, like “Ruby Development” or “Mail Server”.

4. Most who need fine-grained control use Kickstart instead of the GUI

   Plenty of sysadmins have libraries of lovingly handcrafted kickstarts for new systems and getting their packages just so. And woe betide us if we ever mess with their kickstarts!

So this, roughly, is what shaped the mockup:

And what we got in F18:

The “Custom add-on” button is missing – it had to be removed at the last minute due to time constraints, but it’s on the list for Fedora 19. In fact, there are lots of improvements planned all over Anaconda.

But individual package selection is not one of them. (At least, not at the moment.) Because as far as I can see, the use case is very, very narrow:

People with enough expertise to know exactly which packages they’re looking for, but not enough expertise to write a kickstart script to do it for them, and who (for some reason) absolutely cannot install anything after anaconda finishes.

And the alternative solutions (figure out why people don’t use the system tools, and fix those problems; make kickstarts easier to use) benefit far more people, and are much less of a maintenance burden.

The same applies for making anaconda install multiple environments (like GNOME and KDE). This has been discussed to death, but the conclusion is the same: It’s a much better idea to just install GNOME, then install KDE after the installer finishes (or vice-versa). And if you absolutely can’t do that post-install – why not just use a Kickstart?

Why not Kickstart?

Writing a kickstart to select/remove packages and groups is super-easy. Say you want to install KDE and GNOME, and also inkscape, and remove sendmail and any “docs” packages:

%packages
@gnome
@kde
inkscape
-sendmail
-*-docs
%end

That’s it. Really.

Getting the installer to load the kickstart isn’t too hard, and we’re working on ways to make it even easier.

And there are probably other interesting new ways we could make these things easier for our Expert Users. Here’s one off the top of my head: We could expose some simple Kickstart Console that let you just type in kickstart commands, so you could pop up the console, type:

%packages: @gnome @kde inkscape -sendmail -*docs

And off it would go.

Okay, fine, let’s talk a little more about this pony you want…

I’m still open to the idea that we’ve missed some common (or uncommon, but important!) use cases that aren’t covered by either Kickstart, the existing system packaging tools, or the existing installer package selection UI.

There’s plenty of ways we could solve these problems, and I’d really love to hear some new ideas.

But it’s going to take some pretty impressive evidence to convince me that:

1. The only reasonable solution is for the anaconda team to maintain yet another godforsaken package selection UI, and
2. That working on this UI would actually be preferable to quitting computers forever and farming potatoes or something instead.

As always, I look forward to seeing what you come up with!