critical path packages

June 22, 2009

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.

12 Responses to “critical path packages”

  1. Bill Says:

    Well, the problem with depsolving it out into a comps group is that that set changes over time… you’d want to be able to depsolve it out as needed. (Which is doable.)

    Specific comments:
    – firstboot isn’t necessary on a running system
    – xorg-x11-* needs broken down a bit (see: xdm, fonts, etc.)

    • skvidal Says:

      We don’t have to hit in every event – we just have to have a relatively good idea what pkgs are critical path or not. Being perfect isn’t necessary.

  2. luis Says:

    If people are unhappy with the extra bureaucracy, maybe the answer is mandatory automated testing, or mandatory extra time in a high-risk/high-reward public testing channel?

    Realistically, small scale human testing (a couple more eyeballs in releng) is not going to catch much- or at least, not going to catch much that wouldn’t be caught by basic automated tests. (Large-scale human testing would be better than either, but obviously is still hit-or-miss.)

    • skvidal Says:

      This isn’t happening in a vacuum. We’ll be doing a number of automated tests as part of the autoqa process however:
      1. automated testing for 17000 pkgs doesn’t work worth a crap
      2. there are pkgs which matter more out of that 17000 so we have to define that set either way. This is just a way to identify those pkgs
      3. if someone is unhappy that their package is important, then they are more than welcome to find someone else to maintain it. My patience with a maintainer who is responsible for something that is important and doesn’t want to work with releng and QA to make sure it is not going to break everyone is not going to be exceptionally high.

      • luis Says:

        Absolutely right to define the smaller set, and this seems like a reasonable subset to start with.

        (Long-term, I’d disagree that automated testing of every package isn’t worth a crap; it’s only not worth a crap if the tests are not worth a crap. Take the bullet and force people to write real tests, and in the long run we’ll all be better off for it.)

  3. Chris Says:

    So, you mean to define a critical “core” list of packages… Kind of a Fedora Core?


    • skvidal Says:

      No, Fedora Core was a mishmash of whatever was in red hat linux before fedora started. And the difference in how the packages were treated was that extras packages had to be checked and verified before being added to the repo while core packages didn’t go anywhere.
      Now, what we’re making a pitch for is the base set of pkgs you need to do everything else and maintaining those will require extra dilligence and extra effort.

  4. Nicolas Mailhot Says:

    What the h* is bitmap-fonts doing on this list?

    • skvidal Says:

      bitmap-fonts is a mandatory pkg in the “X Window System” group.

      • Nicolas Mailhot Says:

        I suspect investigation x maintainer side will show bitmap-fonts has not been critical anymore for years

        OTOH if you don’t include even a few fontconfigified TTF font packages, you’re going to have problems with any modern gui app

  5. Peter Jones Says:

    No mkinitrd/dracut or plymouth? (The latter I can understand, but the former seems crucial.)

    • skvidal Says:

      The first line before the list mentions all of those pkgs and ALL of their dependencies. I think mkinitrd is required by the kernel and grub and plymouth is required by mkinitrd.

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

%d bloggers like this: