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 :)
- KB
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
Jeff Johnson wrote:
Doing closure checks repeatedly is the traditional way of finding problems.
i suppose this is the easiest way to move forward on this issue..
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.
sounds interesting, but will need to workout how much work is involved in looking at multiple rpmdb's of this nature, I dont want to rebuild the entire rpmdb-centos everytime a new package is built. So the aim would/could be to just have a bog standard one that gets built weekly, and another that changes with 'fresh builds'.
Hmmm, openpkg has pretty good automation, you might ask what they do.
good call, will check with them what / how they manage their stuff.
- KB
-
Jeff Johnson -
Karanbir Singh