pkcon list-install foo.package-list

In newer versions of gnome-packagekit there’s a tool called gpk-service-pack:

Service Pack Creator

Service Pack Creator

This tool I’ve explained in the past, and there is now lots of information and diagrams in the help file about how it all works and what the point of the tool is. Anyway, the point of this blog post isn’t to promote service packs; it’s to scratch an itch that I see coming up when Fedora 10 is released.

The tool exposed one detail to the user: a package list.

This is a simple text file such as hughsie-laptop-f9.package-list. This file allows tools to operate on other similar computers with different packages installed. It’s really just a simple list of all the packages installed. It’s contents and format are unimportant for now as it lets you do some cool stuff.

My personal situation, right now: I’m running a F9/F10/rawhide-ish laptop that I’ve been running for a few months, installing packages using yum, rpm and PackageKit, and have now got all the packages I need for building all my stuff, and all the programs I need on a day-to-day basis.
When F10 comes out, I normally nuke / and reinstall from the live CD as I’ve got so much cruft and brokenness from the months of a rawhide development cycle. On the first boot, I run:

yum -Y install <paste long list of packages from a tomboy note that's got bigger over the years>

Now, what I need is an admin tools that says:

  1. Capture all the package names on my old system
  2. Show me all the differences between what I had then, and what I have now
  3. Use the old package list to install all my normal stuff, not specifying versions

So, two hours of hacking later:

  1. pkcon list-create hughsie-laptop-f9.package-list
  2. pkcon list-diff hughsie-laptop-f9.package-list
  3. pkcon list-install hughsie-laptop-f9.package-list

I know I can do some of step 3 using a custom kickstart if I wanted, but I normally don’t know what I install manually. Maybe it’s only me that’ll find this useful. Code is in git. itch2scratch–;

3 responses to “pkcon list-install foo.package-list”

  1. Mats Taraldsvik

    Neat! A list of manually installed packages would be even better, as that’s normally what you want, right?

    If you make a package list after a fresh install, and then for every update. The diff between updates and the package list + the diff between ‘all packages’ and (‘fresh install’+’updates’) would equal manually installed updates.

  2. backup

    Neat indeed. It would be incredibly useful to have a way to select only manually installed packages like Mats suggested. Hope you get that itch too. :)

  3. John

    I use Mandriva, and just did something very similar (nuked my old install, reinstalling certain packages until I have what I need again). I manually made an alpha-sorted list of my packages without version numbers before the wipe, and have been comparing that to my new install, refreshing the new list as I install new packages.

    A couple of thoughts:

    1) Something that I encountered on my last upgrade was new: I switched from i586 to x86_64. This meant that (at least with Mandriva’s naming convention), I now have a bunch of packages with “lib64″ in the middle of their names, which makes it hard to do a 1-to-1 comparison. Likewise, I imagine, if I ever went back to i586.

    2) What about dependencies which change? My last update jumped several versions of the distro, and so I had a lot of packages that didn’t need to be reinstalled, as well as some new ones that needed to be installed but weren’t by choice.

    Both these cases generate a lot of “background noise” in which my actual choices are lost. I still haven’t gotten everything reinstalled because the “noise” made me decide to only install what I need as I need it. So after the initial (very big) push, there are a bunch of other packages which I haven’t done anything about because I don’t always remember what I had had originally installed by choice or by dependency, and don’t want to take the time to comb through the list.

Bad Behavior has blocked 2769 access attempts in the last 7 days.