On Mon, Mar 03, 2014 at 09:06:15AM +0100, Foresight wrote: > On Mon Mar 3 03:02:55 2014 Michael K. Johnson <[email protected]> wrote: > > First, the code to walk the groups is enough to use. > > Should we let mirrorball fetch the matching comps xml too?
I don't know whether it already loads comps or not. In the end, since the comps don't have a stable filename, we will probably want to have mirrorball be the thing that looks through the comps and writes out a form that the group recipe loads directly. But your code shows the path through the XML that gives the mapping. Thank you! And looking at mirrorball/repomd/ I don't see code to look at comps. mirrorball parses those files with rpath_xmllib which is an object reflector. That's at least way more verbose than a few simple ElementTree iterators, but I don't know whether Elliot has any opinions on whether there is value in using rpath_xmllib for additional parsing in mirrorball or just using ElementTree is fine... > if we have all their packages and if fedora devs did their job. The groups > should be complete anyway. They will be complete with regard to RPM dependencies. Conary finds more and finer-grained dependencies. Some of those dependencies may not be true dependencies and therefore need to be excluded in the factory. So the dependency check will have at least the following functions: * Confirm upstream dependency closure (upstream also tests for this, so not much value here). * Confirm that Conary has not transformed RPM dependencies into Conary dependencies in a way that breaks closure. * Confirm that the "slice of history" we have inferred has dependency closure. * Confirm that the additional dependencies that Conary has found are also closed. As an aside, now you probably have a better idea why an import into Conary takes ongoing maintenance; when an update to upstream breaks the assumptions in the superclasses and factories that drive the update, Conary developers need to be alerted to the breakage and apply judgment to determine whether it is a real problem (repository out of sync with updates, for example) or a need for adding an exception to the factories because it's not a real problem. As you can see, we'll need to check for dependency closure on the whole group at least at first, and probably always. And for groups that are part of Conary conventions instead of upstream groups, we will probably close dependencies within those groups. But for the upstream groups, we are trying to faithfully represent the upstream groups within the limits of our technology, and so should not close them. And if the set of all packages is dependency-closed, then any subset is closed with respect to the set of all packages. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
