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- 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: 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?

Fedora 17 package selection screen

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:

Software Selection Mockup

And what we got in F18:

Software Selection 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:


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!


10 thoughts on “Package handling in anaconda – another retrospective

  1. How about in addition to making a nice gui for detecting kickstart files, why not a simple gui for creating a kickstart file? I don’t know where you would grab the package names from but instead of the user having to type in “inkscape” for example, inkscape would be in the gui’s list and a checkbox would be by its name. Sounds simple enough and I think would satisfy the users request for package choices on installation.

    • How about in addition to making a nice gui for detecting kickstart files, why not a simple gui for creating a kickstart file?

      We actually do have such a thing! It’s called system-config-kickstart.

      It might be a little broken at the moment but we’re fixing it up to work with the new anaconda as quick as we can. And it does have a fine-grained package selection UI.

      And the UI it has, until someone writes something better, is: pirut.

      It just will not die. Heaven help us.

  2. Personally, I really liked the software selection. I would go through each category, and deselect any optional package I didn’t need; while I like the gnome desktop, I really only use some of the core apps. So, my install is usually reduced to 700-800 packages or so. With the GUI, I could point and click through in about 10 minutes.

    Granted, f18 made me learn to use a kickstart file; while it wasn’t difficult, it DID delay my installation by a day or so. First, it’s not exactly easy to find out which packages are included by default. I had to dig through a combination of the comps git repo, and also get the default list of packages from the spins git repo. Then, I trimmed some XML output to get a nice list of packages. This wasn’t exactly easy to discover, for being such a “simple” alternative. Each package Group had its own section in the various files – getting the default list of “Desktop” packages was not trivial.

    Sure, I consider myself advanced enough to go through such trouble, to get exactly what I want; but I wonder how many new users would know what the words “kickstart,” “anaconda” even mean, while the GUI spells it out pretty understandably, with nice, short package descriptions. While I can do “-cheese,” because I know that I don’t have a webcam, it’s probably not as obvious to someone else; where as the short description containing “Application for taking pictures and movies from a webcam” would be pretty easy to grasp as a new user to Gnome.

    • Sure, you want a minimal desktop. I get that. In fact, lots of people seem to want that.

      But guess what? That’s easy to do with the new UI! We’d just have to add “Minimal Desktop” to comps.xml, with a shorter list of core packages. We could even have add-on checkboxes for each of the apps – “Cheese”, “LibreOffice”, and so on – so you can pick only the ones you want. Heck, later we could make it so the apps can have their correct icons, and descriptions and stuff.

      That might even end up being nicer than the old way – certainly less than 10 minutes worth of clicking, right?

      And I think there’s a bunch of big groups of people like this – everyone in the group wants approximately the same thing (“We want to be able to install a Minimal Desktop!”), with some variations (“…except I want Inkscape too!”). And all we’d have to do is work together to get the right things into comps and we’ll end up with something that’s better and easier than what we had before, and everyone goes home happy.

      You know why this isn’t in comps already? Because everyone just used to using the custom packaging UI. They knew exactly what 38 things they needed to click to install their Minimal Desktop, so why bother going to extra effort?

      So we have all these big groups of people asking for the same thing:

      “Give us package selection back!”

      When what they really want is more like:

      “Give us a Minimal Desktop!”
      “Give us a totally stripped-down machine!”
      “Give us KDE and GNOME! And LXDE! And MATE! Ooh xmonad!! And E17!! I GOTTA CATCH THEM ALL!!”

      Wouldn’t it be better for everybody if we sat down and figured out how to better give you what you actually want? Because absolutely nobody’s favorite thing to do with their computer is “package management!”

      Except maybe that last dude. He’s a bit nuts, I think.

      • Yeah 🙂 I agree that my particular use case is interesting. The problem with starting with a minimal, and using yum to group-install Gnome, is that I’m not further ahead than using the standard Desktop set.

        So, perhaps my complaint with the kickstarter option isn’t the trouble of creating one – for me, it was figuring out package lists. It was *very* tough to find what “Gnome Desktop” included – perhaps a list could be generated for each release, to make this step a bit easier? Had I not been familiar with comps.git (that is, even know what comps was, where it was hosted, etc), I probably never would have been able to create such a list.

        And for the record, while I wasn’ t after a totally trimmed Gnome install, I did end up getting exactly what I wanted this way 🙂

      • I appreciate the fact that you and Mairin have been open and cool headed about this discussion. I have only one last thing to say on this subject.

        You said in regards to everyone’s diverging needs: “Wouldn’t it be better for everybody if we sat down and figured out how to better give you what you actually want?”

        Well, I would ask you, how much work would have to be done to give everyone what the want? How much work is done maintaining the spins? Those spins are basically customized installs so that the users don’t have to select the packages themselves. On a cost analysis basis, is it better to try to meet everyone’s needs individually, or at least many of the popular ones, versus the work load of adding and maintaining a package selection screen to Anaconda?

        On a side note for future releases, it would be really nice if we could pick any of the official spins as a build option from the DVD.

  3. Will & co., has there been any thought already on the capability to edit a kickstart file on the fly in the installer UI? I’m thinking of someone putting in the small list you described in your blog post above, i.e. four or five of their favorite packages, without having to go prep some mountable media with a .ks file.

    • Right – that’s kind of what I was suggesting in the “kickstart console” idea I mentioned in the post.

      I might try putting together a prototype and seeing what the rest of the team/world thinks, but it’s not something we’re actively developing at the moment.

      • Will, I absolutely LOVE the idea of a kickstart console! That would be brilliant. I work in GSS (Red Hat support) and I can tell you that it wouldn’t just be me and other employees that would love having something like that. Damn that would be awesome.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s