[pacman-dev] [patch] testdb, reworked

[Nagy Gabor]

> 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