3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Yes, I think so.;-)

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. Well, I don't think we can easily compare the current codebase with 2.9.8. There were _dozens_ of bugs in 2.9.8, after 3.1.3 release we got no "real" bugreport in FR. I think library is better than some server<->client stuff, because now we can easily share internal things with the front-end (for example: pkgcache) without interchanging tons of data. So my vote: keep libalpm library.

Bye

Hey there, I've been thinking about libalpm recently since I started maintaining aurbuild. I haven't looked at any of the code of libalpm (yet). Yes, I have heard about how it's ugly and so on. I've seen all the stalled attempts at creating python bindings as well. I contacted one of those projects:

The thing that has to be done before thinking of using pyalpm is implementing the transaction system from libalpm. It'll be a real pain because, until the last time I've checked it, it was made in a "flag-return_value-more_flag" way, which make it very hard to wrap for python (at least using pyrex, as I was). So good luck if you'll try

Well I'm still determined to try just to let you know. I'm willing to provide input and get involved with libalpm eventually. It could be useful for some other archlinux projects too like repoman and pacbuild. And who knows, maybe even a sleek new python based, command-line oriented AUR. I'm stretching, but this is a wacky idea of mine. There was some casual talk among some AUR hackers about hooking into libalpm back in October or something. On Thu, 27 Mar 2008 12:33:18 -0500 "Dan McGee" wrote:

It is clear to us on the list that no one has really latched on to using libalpm. There could be all kinds of different reasons for this, but it's mostly important that libalpm should work for pacman

So, what does this lead us to? 1. Document the existing interface better. Definitely

2. Frontend developers need to speak up and get ideas on this list. Here I am. Though my input will be largely dependent on how my other work progresses. There's only 24 hours in a day unfortunately.

3. Scrap the whole libalpm/split idea. I guess that would depend on the purpose libalpm was created in the first place. If you could ever envision more than one application using the libraries at the same time I would vote to keep libalpm. I can imagine a setup where I have a software checking the database, building, and installing packages in a syncronised manner.

4. Switch to something like python. Though that might make things easier for me (and some others), I don't

It seems that at least one app (shaman) uses libalpm in a serious manner so it would be kind of mean to scrap it. But I guess you can't be nice for nice's sake. Hah. think it would really be a good approach for pacman/libalpm. Unless it was pyrex, or cython maybe hah. But still I'd say no. Cheers!