On May 20, 2007, at 7:49 PM, Karanbir Singh wrote: > so before I go reinvent the wheel... > > does anyone want to recommend a process / toolset that can check > for fixed-version deps in a repository and rebuild the failing deps > against a new version of the deprecated package ? > > eg. when a new kernel is built, I want to get a list of all the > packages in the repo that depended on the older version of the > kernel, and who no longer work with the newer one. If there are > hooks in this tool to allow me to plumb in a auto-rebuild-into-a- > testing-repo process, that would be star! > > The most obvious way seems to be checking the entire repo for > closure and whatever fails, take some action - but that is not a > really good way to check which side is failing. And it also means > the new rpms need to be already in a binary format before I can run > the test, so thats not going to work. > > What I was thinking of doing was to import the repo metadata, > remove details for the package being superseded, get a before and > after picture, then queue in the now-failing packages behind the > new package being built. > > Things get even more interesting when there are a bunch of packages > being built. But we can think about that later :) > Doing closure checks repeatedly is the traditional way of finding problems. There are issues with multiple Provides: that need to be considered. Hint: creating and configuring and maintaining a rpmdb-centos package will permit easy translation back to package srpm's. rpm-metadata often lacks complete file info. ANd if you don't have reliable metadata in db's, well its a hard problem to figger what else needs to be rebuilt if something changes. Hmmm, openpkg has pretty good automation, you might ask what they do. 73 de Jeff