Nagy Gabor wrote: >> commit f43805d875ad5c672afbbfff48bded2087204773 >> Author: Chantry Xavier<[EMAIL PROTECTED]> >> Date: Sat May 10 18:47:42 2008 +0200 >> >> Cleanup usages of alpm_list_find and alpm_list_remove. >> >> * remove obsolete and unused *_cmp helper functions like deppkg_cmp and >> _alpm_grp_cmp >> >> * new alpm_list_remove_str function, used 6 times in handle.c >> >> * remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by >> a more general alpm_find_pkg_satisfiers with a cleaner implementation. >> before: alpm_db_whatprovides(db, targ) >> after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ) > > Warning: pkg literal also satisfies pkg. But in most cases we called > what_provides if we didn't find a literal. >
I know, it's not exactly equivalent but I think it makes more sense that way and as you noticed, it works the same for our use case. >> * remove satisfycmp and replace alpm_list_find + satisfycmp usage by >> _alpm_find_dep_satisfiers. >> before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp) >> after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep) > > Warning: possible slowdown, the old way just stopped after a satisfier (which > is ideal in checkdeps), now we scan the whole db. > Right, I knew about that too, I just wanted to keep the code as clean as possible and didn't find another way. Though it might be worth to do some benchmarking / profiling. If it's really too bad, it will have to change. >> >> * remove _alpm_pkgname_pkg_cmp, which was used with alpm_list_remove, >> and >> use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead. >> > > Imho this is ugly. First we find it, then we again find it via list_remove. > > Yeah, it's not ideal either. But neither are dummy pkg or fake asymmetric cmp functions. I just preferred it like that. Imo the real problem here is that our data structures suck and are inefficient. Linear search ftw. Anyway, other better suggestions for these 3 points are always welcome. _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
