[Yum] creating build order from rpm spec files

[seth vidal]

On Tue, 2011-10-25 at 03:19 +0000, Alfred Landrum wrote:
> I'm using the yum python api for the first time, and would appreciate
> Any comments or guidance.
> 
> I've created a small utility that takes a set of rpm spec files and one or
> more live yum repos, determines if the spec files can be built, and if so,
> what is the required build order according to their dependencies.
> 
> This requires an extremely recent rpm lib, so that the rpm.parseSpec
> result will generate the 'implicit self-provides' packages.  (See
> correspondence with Panu Matilainen here :
> http://lists.rpm.org/pipermail/rpm-list/2011-October/001020.html )
> 
> The utility works by:
> - instantiating a yumbase instance using the supplied repos
> - uses rpm.ts().parseSpec to get the rpm headers of the source & built
> packages from a .spec file
> - uses yum.packages.YumHeaderPackage and yum.packages.FakeRepository to
> create a yum package from the rpm headers
> 
> It then creates a build order tree:
> - finds source packages whose 'requires' are met by calling
> returnPackageByDep on their dependencies.
> - if the source package can be built, creates a fake package sack to hold
> the built packages, and adds them to the yumbase .pkgSack metasack.
> - iterates until no more source packages are left, or can be built.
> 

Alfred,
 I look forward to seeing the code: How are you breaking circular build
deps? 

Do you try to look at other srpms to see if they would likely build into
a pkg which will provide what something else requires in order to sort
the build order? or are you counting on having an existent repository
which is 'close enough' to draw from? what about obsoletes or pkgs
changing names between them? How are you handling that?

When I worked on this problem before I found that circular build deps
and not-quite-specified-enough build deps  - especially when pkgs
changed names or changed where the provider lived were very common and
wrought havoc over any ordering I tried to do.

It worked for small sets of pkgs - but if I passed in something like a
big stack of gnome pkgs it returned unreliable results.

thanks for working on this!
-sv