[pacman-dev] Libalpm direction and usage by others

[Xavier]

Dario Freddi wrote:
>>   
> This is my thought. Out there, a lot of people have great ideas about 
> pacman/alpm, but nobody here ever seemed to have listened to them. You 
> asked for some code, I brought you Shaman. I'm ready to get up with some 
> well documented ideas, but I don't know if there is the right attitude 
> to accept other point of views. And I'm not talking about the SQLite 
> stuff - I hate SQLite, and it sucks for a package manager. But 
> honestly... would you give alpm the fault for all those void*s, for all 
> that useless package structs, and whatever else?
> 
> There is someone who latched over libalpm, and it's me. I believed in 
> it, even a lot of stuff was wrong, and the result is Shaman. You can say 
> you don't like it, ok, that's fine. What you can't say is that it is a 
> real step forward compared to gtkpacman & friends, that used pacman 
> instead (I'm not saying they're bad, I'm just showing the difference in 
> wrapping pacman and libalpm, gtkpacman still remains a piece of software 
> IMHO)
> 
>> -Dan
>>   
> Didn't mean to offend anyone, sorry if I did.
> Cheers
> Dario
> 

Well, I am not sure why you felt offended, Dan didn't mean it that way.

What you did is indeed great, that would be the first real frontend 
using libalpm. (well there is also gfpm using frugalware's libpacman, 
but I don't think anyone really ported it to libalpm, at least it's not 
uptodate).
But actually, that's the point, you are the only one, while there are 
countless of others tools simply calling pacman, or parsing the stuff 
themselves.
Still, your project should give us a better idea about the quality and 
usefulness of libalpm, and I hope that you will have concrete 
suggestions for improving libalpm and making it more friendly to use :)