Um, bigger problems here.
1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory. Well, I wrote in my first e-mail in this thread that I wasn't familiar in these alpm public/private/whatever and naming conventions, so I wanted to let you clean-up this part (I hoped, that the patch is helpful with this glitch, too). And you are the "leader", you should choose the right conflict-checker funtion to be public, and give them a good name (alpm_*). See also: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009549.html 2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.) This is in git already. 3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility. See 1. 4. FREELIST? libalpm private function. I don't understand this (anyway, that is a macro). "#include <alpm_list.h>" is not allowed (this is in git/testdb.c already)? Then how should be work with alpm_lists? Sorry to burst anyone's hopes here, but this patch just isn't acceptable right now. OK, but keep your eyes on the remaining bugs in testdb.c.
OK. I try to explain what my problem is: If I send a patch, I have the feeling that it will be committed without modification or rejected. But this is a teamwork, so you can improve/fix my patch before commit. I don't care if you modify my patch, I don't care if my name is not listed as patch-author etc.; I suppose that before committing all accepted patch is carefully read, so fixing/improving is not an extra work IMHO, so I suggest to do that. For example, there are parts in my big checkdeps/alpm_sync_prepare patches which I don't like (the 2in1 remove+upgrade list loop for example); but that parts are unimportant; and (1.) I trust on your creativity and (2.) I couldn't do it better. Back to the current patch: First of all, I'm not a programmer, so I have few experience in c-programming. And to tell the truth I was never interested in "programming language syntaxes", I'm interested in algorithmic problems instead. So I _knew_ that my patch is not perfect, but I hoped that it will be helpful (it points to some bugs and its concept is (hopefully) good.); but I also knew, that even a 5-year-old kid can fix it, if he knows C static/public/whatever syntax and alpm function-naming conversions. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/