[pacman-dev] [patch] testdb, reworked

Nagy Gabor ngaba at bibl.u-szeged.hu
Fri Oct 26 07:40:25 EDT 2007

> > 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.
> Bye, ngaba
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
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.

More information about the pacman-dev mailing list