[pacman-dev] [patch] testdb, reworked

[Nagy Gabor]

> > 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/