It is clear to us on the list that no one has really latched on to using libalpm.

Don't agree

To be honest, I don't blame anyone for this, as the interface seems to have been drawn at a bad level, and calling things like alpm_trans_commit() after 6 other functions and setting flags right just isn't intuitive.

Agreed.

So, what does this lead us to? 1. Document the existing interface better. Although it isn't perfect, we aren't going to get frontend clients without documentation. As all of us working on the one client that does use libalpm (pacman) have clearly not felt a need for further documentation, this is really going to have to be spearheaded by someone outside of our current "normal" developers. Anyone want to step up?

Stop on that. When I started my work, I had only this (http://code.toofishes.net/pacman/doc/index.html) and the code. You know what? That was enough, and I didn't EVER complain about it. A competent programmer knows that, even if he had the best documentation around, sooner or later he will have to see the code to understand how things **really** work out. Sure, an improvement could be good, but don't forget that something is already out there.

2. Frontend developers need to speak up and get ideas on this list. I constantly see rhetoric like the above, where people say the current API is not very good, but they have not done a damn thing to change it. We can't read minds here, and we also aren't going to just change things on our own. So speak up people! If we get some good discussion going, we could really make changes to the API to make it usable.

I once sent a mail, I proposed some ideas, I got one (1) answer, and... what? I proposed to abstract the backend, some real things, I'm writing a whole paper on that, I'm ready to show you something REAL, some real ideas, some people who really want to do that but... where is the list? Why just shining answered to my mail? Why didn't anybody else step up and said: "Ok good" or "No, sucks". You wanna see some code? Some efforts? Is that one enough? http://shaman.iskrembilen.com/trac.cgi/wiki I wrapped libalpm around a C++ class and guess what? It works. It still has issues, but shaman works, and while I'm writing, a lot of people are using it, even if I still haven't put it on Arch bbs, since I want it to reach a real beta stage (where beta means usable, feature full, with some minor stuff, something we've almost achieved). Will somebody listen to that now? Will somebody say that alpm, library or not, needs improvements and not in the code, in the basic ideas around it? Will somebody finally admit that it's time to hear other voices? In my opinion, simplicity is also making life easier. Having a choice between db frontends is simple, since everyone can write its backend, and it gives the user freedom to use whatever it wants.

3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Would it? I can tell you this- the pacman 2.9.8 codebase was about half the size of the current monster, and we have a lot of crazy design issues going on. Instead of trying to write a pacman library, why not just implement a friendly frontend, command-line interface, which is a bit more Unix-y? For example, monotone has its "automate" command (I haven't looked at this in some time, so let me know if I am wrong) that is designed to be used by other clients as machine-parseable. git is based around this concept as well- look at all the low level tools like rev-parse, etc. 4. Switch to something like python. I'm resistant to this idea. Although I think scripting languages like this have great benefits, I don't think pacman needs most of them. Having a package manager that always works is important to me, and part of me just thinks a low-level compiled language is the right thing for a system tool.

Python or not, don't even think on that. First of all, all our efforts into shaman would be a waste. Secondly, you close every door through a different frontend than pacman, and I don't really think this is really the Arch way.

Of the four options above, I have been pushing 1 and/or 2 for a long time. However, I am starting to lean toward option 3. I'd love to hear your thoughts on this.

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