critical path packages

Lo’  nearly a week ago we had a FAD and came up with some proposals. One of the proposals was Critical Path Packages. The gist of this proposal is that all packages are equal, but some are more equal than others. Or to put it another way – there are a set of packages that will need to jump through an extra hoop if the maintainer pushes an update.

There a bunch of areas where we want to be sure the packages all work together, so I made a brief list of the pkgs involved in those areas:

Deps of these pkgs included:

• graphical network install
  • anaconda
• post-install booting
  • firstboot
  • grub/bootmanager
  • kernel
• decrypt encrypted filesystems
  • cryptsetup-luks
• graphics
  • bitmap-fonts
  • desktop-backgrounds-basic
  • xorg-x11-drivers
  • xorg-x11-server-Xorg
  • xorg-x11-xauth
  • xorg-x11-xinit
  • gdm
  • mandatory pkgs in gnome group
• login
  • gdm
  • pam
• networking
  • NetworkManager?
• get updates
  • yum
• minimal buildroot
  • bash
  • bzip2
  • coreutils
  • cpio
  • diffutils
  • fedora-release
  • findutils
  • gawk
  • gcc
  • gcc-c++
  • grep
  • gzip
  • info
  • make
  • patch
  • redhat-rpm-config
  • rpm-build
  • sed
  • shadow-utils
  • tar
  • unzip
  • util-linux-ng
  • which
• compose new trees
  • pungi
  • mash
  • createrepo

• compose live
  • livecd-creator
  • pungi

I’m thinking of depsolving out the complete list, uniquing it and creating a new comps group which includes these pkgs as mandatory members so it can be referenced easily.

Anyone with a package in this group will have to get some member of releng and QA to sign off on the package update going through before it happens. I realize this is an extra level of bureaucracy but I don’t think we have any choice. For an example problem that we could have avoided if another person had to test and signoff on the update I’d like to refer everyone to the dbus update from earlier in the F10 release.

I’m looking for feedback on this idea, but I’ll probably go ahead with some of it as-is.

yum benchmarks

About 30dozen people sent me to the test comparing yum to apt-deb. Always a fun comparison. It’d be even more fun if any of the numbers seemed accurate.

I put a short script together for myself – just to see how yum is doing.

Here’s the very simple script:

http://skvidal.fedorapeople.org/misc/yum-test.sh.txt

I ran it like this:

sudo ./yum-test.sh >> /tmp/simple-yum-results.txt 2>&1

Here are my results on my x61s laptop running F11:

http://skvidal.fedorapeople.org/misc/simple-yum-results.txt

Full disclosure. I had already updated the metadata b/c I didn’t feel like testing the network speed in this coffee shop. I also downloaded the pkgs that it installed already by pulling them into the cache with a yumdownloader. Again, I wanted to test yum (and rpm) not the bandwidth of  the coffee shop. I’m running yum 3.2.23-3.fc11 on a 686 install of f11.

Overall the numbers look pretty good to me. Run a test for yourself and point out your results below.

Update enabled repos for the benchmarks

sudo yum repolist
repo id             repo name                                 status
fedora              Fedora 11 – i386                          enabled: 13,289
updates            Fedora 11 – i386 – Updates                enabled:  1,988
repolist: 15,277

munging rpm diff

For checking changes from one package to another we’ve discussed a better rpmdiff that wouldn’t report so many bogons in the filelists and provides, requires, obsoletes, conflicts.

After giving it a bit of a think I worked out a mungingdiff for pkgs.

It reports items that matter, not all the stuff you EXPECT to change. For example:

if the pkg goes from foo-1.1-1 to foo-1.2-1

and its provides change from:

Provides: fooball = 1.1-1

to

Provides: fooball = 1.2-1

it’s a little silly to report that in a diff. Same thing with filenames. If a bunch of files move from /usr/share/doc/foo-1.1 to /usr/share/doc/foo-1.2 but don’t change otherwise does it matter? No. Not in any functional way.

So I cobbled together a proof of concept that I’ll be moving internal to yum package objects so they can provide a diff between two pkg objects, I think.

http://skvidal.fedorapeople.org/misc/mungingdiff.py

Run it like:

mungingdiff.py pkg1 pkg2

a couple of minor things. It doesn’t return diffs between the name, arch, epoch, ver, release. It is working on the assumption that if you don’t know those things have changed then you’re Sorry out of Luck.

I also know the output sucks, big surprise.

just in case anyone asks

I updated to fedora 11 from the mishmash my laptop was today. I did it in three steps b/c I was going out for dinner.

All of these steps were run in screen:

1. yum –downloadonly update

2. yum update

3. yum groupupdate “GNOME Desktop Environment”

then I removed a bunch of packages I didn’t want and checked to see if evolution works with vfolders of vfolders (it doesn’t). Maybe I’ll try thunderbird out.

But, for the record – yum updating in place worked – but do it in screen b/c of the fontconfig issue that’s documented on the common issues page.

Fedora Activity Day – Raleigh

just to be clear the phone was only muted at all today b/c:

a. Josh wanted to talk some smack about my parentage and we didn’t think everyone needed to hear it

b. Spot was playing some inappropriate SNL videos

c. We were playing that game that asok the intern played badly with speaker phones

d. all of the above.

Seriously, FAD today was the big – what things we have problems with and why. You might think this would be an easy thing but in reality with N people in the room you tend to have N^N number of opinions on what is wrong. So we had to hash out a consensus of what was wrong.

We got through about 1/3rd of our list you can find these things on the FAD wiki page. There is hope for more tomorrow.

Then we had pizza and popsicles.