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
- post-install booting
- decrypt encrypted filesystems
- mandatory pkgs in gnome group
- get updates
- minimal buildroot
- compose new trees
- compose live
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.