On Fri, Oct 26, 2007 at 01:40:25PM +0200, Nagy Gabor wrote:
I'm planning to rework the patch. I start to agree with VMiklos, who said that testdb should me merged to pacman. What's more, I'm saying testdb should me merged to libalpm: then almost all of the problems listed above would disappear. I would like to add one more argument: If you give a look at my reworked patch, you will notice that it directly modifies pkg->requiredby, which is an ugly thing: it should be done through libalpm api; however, libalpm has no alpm_pkg_set_requiredby or similar function <- that would be used rarely. So merging the whole testdb stuff to libalpm would eliminate the public/non-public argument and IMHO testdb can fit in libalpm. And pacman is the best front-end for testdb, IMHO (for programmers and users).
Any feedback appreciated, ngaba
PS: So now it is not so important to implement a more powerful _public_ conflict checking function to libalpm. I would still prefer it.
Well, I asked back then where testdb would suit the best, and it seems like no one had a strong opinion. Seems like Dan thought an external tool was a good idea, so that's how I started writing it. Later vmiklos said he had a slight preference for keeping the stuff in libalpm. But I didn't find it enough to change it back. I said -Qtt (but probably that was too late);-): http://www.archlinux.org/pipermail/pacman-dev/2007-September/009252.html Hm, now I remember that Dan didn't like how the old -Qt option was written in libalpm, maybe because the lib shouldn't return the error/warning message as strings or list of strings. Or something in this spirit, I don't really remember.. Indeed, it shouldn't return with anything. It simply should use _alpm_log. Whatever we decide, these things should be fixed. But we should make a decision first. Then I (or Xavier? ;-) will implement it. As Xavier said, if we stay with the external testdb, we can create a copy of the requiredby lists and then sort that. (But that is needless, because sorted requiredby list doesn't hurt anything.) One more thing, that you won't like: If I hadn't read alpm_list_msort's source, then I wouldn't have found this bug, so at least the comment before alpm_list_msort should mention that it will sort the list "in place" and it won't create a new (sorted) list. Maybe I should know mergesort algorithm better ;-) Bye, ngaba