>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. This utility is part of a prototype for a internal build system here at Riverbed; since most of the code we build is developed in-house, we'll have more options for handling circular deps when they come up - like talking to the handful of development teams about changing their deps - than a distro would. Since we also build packages from the outside world, though, we will have to handle them. We'll identify some (hopefully small) set of binary rpms that are needed to seed a base repository, and then use that to pull from as needed. From what I understand, that's how Koji works as well. >It worked for small sets of pkgs - but if I passed in something like a >big stack of gnome pkgs it returned unreliable results. Yeah - when I first started working on this, I grabbed a handful of specfiles (m4, texinfo, and a few others) and was quite surprised at the circular dependencies I found, even on what I thought would have been small, standalone packages. It's been an education reading about the Fedora build process, especially that the mass rebuilds usually happen w/o any dependency order. _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
