On Wed, 2012-01-18 at 11:55 -0500, Zdenek Pavlas wrote: > > > I'd rather keep bestPackageFromList() as-is, and patch > > > the return path of searchProvides() (unless there's a catch). > > > > You mean doing a second "compare_providers" after compare_providers? > > Seem like a bad idea, and means we can't make depsolving requires use > > the same logic (without copy and pasting it, or creating a > > compare_providers2 or something ... urk). > > I meant that searchProvides() knows the provide name used to find > the packages, and if all packages found have a nice version on that > provide, it could a) prune the list b) sort the list c) assign > some initial score (well, that's an api breakage, probably).
Doing it before, or after is the same basic problem: 1. You can't then use that for other compare_provider() callers, without copy&paste or having compare_providers2(). 2. If you do it before, it overrides arch/updates/obsoletes/etc. checks, which is probably bad. If you do it after, you have to workaround requirements/namelen. ...I'm tempted to just NAK it if you think the API pain isn't worth it, the case the BZ was opened for (and someone nagged me for an hour on IRC) is now fixed. Similar cases have come up a couple of times before, but they are often bugs and if not just a general case of "two possibilities for XYZ, and we don't have suggests/whatever" _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
