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.
June 22, 2009 at 8:50 pm
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.)
June 22, 2009 at 8:56 pm
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.
June 22, 2009 at 8:53 pm
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.)
June 22, 2009 at 8:58 pm
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.
June 23, 2009 at 6:16 pm
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.)
June 23, 2009 at 3:28 am
So, you mean to define a critical “core” list of packages… Kind of a Fedora Core?
June 23, 2009 at 3:42 am
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.
June 23, 2009 at 9:13 am
What the h* is bitmap-fonts doing on this list?
June 23, 2009 at 11:11 am
bitmap-fonts is a mandatory pkg in the “X Window System” group.
June 23, 2009 at 9:42 pm
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
June 23, 2009 at 2:19 pm
No mkinitrd/dracut or plymouth? (The latter I can understand, but the former seems crucial.)
June 23, 2009 at 2:21 pm
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.