Out of order: On 10/19/06, VMiklos <vmiklos@frugalware.org> wrote:
Bindings are here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman What do you mean?
3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing
Not sure what you mean - the only translations I have from the patch are hungarian.
10) i think you forgot to cvs add the /pactest/tests/ directory They show up for me: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/pactest/tests/?search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD
hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update
Can anyone else reproduce this? It's possible I'm just cvs-inept and missed something important - but they show up in viewcvs....
4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users)
According to CVS, NoUpgrade was never removed. This is the latest: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/etc/Attic/pacman.conf?rev=HEAD&search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
yes, but those files should be marked as backup in the relevant packages instead of simply specifying them as noupgrade. i mean, since the following change:
2006-01-22 03:30 judd
* lib/libalpm/add.c: changed behaviour with original=X,current=Y,new=Z backup scenario -- install new file as .pacnew and keep old one in place
there is no good reason to list config files both in backup() and in the noupgrade list. noupgrade is for users to mark files which are not in the packages' backup()
Right, all I was saying has to do with the "left" portion of what you said. I didn't really leave anything as I was never aware that they needed to be removed... I will look into it, as I don't *yet) have all the details of this change.
6) you've added a new callback parameter to alpm_db_register() which is totally useless imho. the callback is called with the treename (which is a parameter, too) and the database pointer, which is returned. so what's the point of it?
The point is that I changed this function to return the existing DB in an attempt to reregister, in place of returning null. It seems stupid to let this fail:
[current] Server = a [current] Server = b
Every config file parser I've seen for sectioned configs ([section name]) parses this as if they were all one section. As such, the change requires the callback because only db_register knows when the database is new or old. It's a rather trivial change, and not "totally useless", as it allows for more valid config file handling.
hm. but still, now alpm_db_update() requires a second parameter that will be always NULL in all frontends. what about adding an _alpm_db_update() function with the callback so that alpm_db_update() could be still called without specifying a callback?
On a personal note, I don't have a problem with "mostly null" parameters - many ANSI C and POSIX functions are invoked this way. This would be much easier if it were C++ (note: I'm being snarky, I prefer C++ by leaps and bounds over C - C++ would shrik libalpm nearly in half... but that's not my decision, heh). 8) I guess having two functions is not a huge deal.... I can add that.