2008/5/14 Nagy Gabor <firstname.lastname@example.org>:
> http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commitdiff;h=9bde1c36eb10ff121f7de5bb34ad e2a704f49c82
> > > (nice jab there, pretty mature)
> > oh well, different targets. this is just a decision. we try to keep a
> > stable api, you don't. both has benefits. and at the end users can
> > choose. that's the best
> IIRC, this was reverted, but that is just one more argument to your 'not stable
> API' "campaign".
It doesn't make any sense to stabilize such a crappy API.
But just as reminder, the API remains stable between minor releases
(3.x.y), but not between major releases (3.x)
About the dltotal thing, Dan indeed reverted it, but we need to add
that feature back with another way.
We currently have this callback :
void cb_dl_progress(const char *filename, int xfered, int total)
Dan suggested to add another one 2 days ago, I believe it was something like :
void cb_dl_total_progress(int xfered, int total)
But I already forgot. Dan, can you confirm this?
> In my opinion the parameters of callback functions should be reworked (warning,
> API change ;-). My preferred solution would be putting one param, a pointer to a
> complicated union or whatever, which can be accessed via
> alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?
This might not be a bad idea, any work that would allow us to get rid
of these TODO in callback.c is welcome :
/* TODO this is one of the worst ever functions written. void *data ? wtf */
/* TODO we take this route based on data2 being not null? WTF */
pacman-dev mailing list