2008/3/27, Nagy Gabor :

...

Hm, it has an interesting frontend to pacman - PacTrac. I especially like the dependency tree: http://www.faunos.com/images/ver-0.5.4-stable/pactrac-install.png

Do we know something about its license or source code? Is this a native libalpm stuff or not?

No idea. I think there should be sources somewhere on faunos.com -- Roman Kyrylych (Роман Кирилич)

matthias@archlinux.de wrote:

...

2008/3/27, Nagy Gabor :

...

Do we know something about its license or source code? Is this a native libalpm stuff or not?

No idea. I think there should be sources somewhere on faunos.com

Here is a link: http://viewvc.faunos.com/viewvc.cgi/src/pactrac/ License should be GPL2 (like the rest of Faun.

Funny. Either people think libalpm sucks so much than it's not even worth trying to use and improve, or writing bindings is too complicated and not worth it? Or a little of both. Seems like pacman3 is quite useless, when are we going back to pacman2? :) Or maybe it should just be directly written in a language where ppl could more easily write a gui (or other tools) in? Like python maybe. That way, anyone can write pacman related tools without reinventing the wheel every single time. Seeing all these tools either calling pacman directly, or redoing all the work themselves by parsing the config and metainfo files make me cry.

Raymano Garibaldi wrote:

You can not expect people to use an API that has no clear documentation and no stable interface that they can count on. And you can not expect a developer to try to figure out an API by scanning mailing lists, at least not this one. If it takes anyone longer to figure out an API than write their own software, well guess what they're going to do.

Then why don't they write an API with a clear documentation and a stable interface so that everyone could reuse it ? :)

Currently I am keeping a close eye on Shaman, http://shaman.iskrembilen.com Very promising but hasn't stablized yet.

That looks interesting indeed. And btw, it's probably easier to figure out the API by looking at pacman rather than this ML, and that's apparently what Shaman authors did. I was just thinking that maybe ppl who needs an API are in a better place for improving it and help stabilizing it. But maybe not.

Lack of documentation for libalpm is the main reason why we didn't use it. As far as I'm concerned the libalpm documentation is a joke (http://www.archlinux.org/pacman/libalpm.3.html). We also read in the forums and the pacman website that it was not finalized and it might change.

Well, IMHO looking into pacman's (front-end) source is better than any documentation. However, you are right, we doesn't have full documentation, but have some doxygen stuff here: http://code.toofishes.net/pacman/doc/

You can not expect people to use an API that has no clear documentation and no stable interface that they can count on. And you can not expect a developer to try to figure out an API by scanning mailing lists, at least not this one. If it takes anyone longer to figure out an API than write their own software, well guess what they're going to do.

See configure.ac (and its history in master and maint branch: http://projects.archlinux.org/git/?p=pacman.git;a=summary), and LIB_VERSION=`expr lib_current - lib_age`.lib_age.lib_revision formula. API change is permitted in master (devel) branch only, maint branch is for the current 3.1.x "series". So in fact you can experience API change only between real releases (terminology of configure.ac), so between the alpm libraries shipped with 3.0.x, 3.1.y and 3.2.z. But you can also experience tons of super new features in real releases, so it is also recommended to upgrade your GUI to use them (even if we didn't change syntactically anything in API):-P

Currently I am keeping a close eye on Shaman, http://shaman.iskrembilen.com Very promising but hasn't stablized yet.

Regards, Raymano

pl could more easily write a gui (or other tools) in? Like python maybe. That way, anyone can write pacman related tools without reinventing the wheel every single time. Seeing all these tools either calling pacman directly, or redoing all the work themselves by parsing the config and metainfo files make me cry.

I agree. Personally I think that the main reason for missing GUI is simple: ArchLinux users don't really need that. And we are not motivated in developing GUIs neither. As a programmer, I think that libalpm is more than programmer friendly. However, we don't have full documentation yet... I agree with vmiklos, that missing config parser can also be a small reason here. Independent from this, personally I would use an external "powerful" config parser/WRITER library (no, not XML;-). In my own projects I'm using scconf: http://www.opensc-project.org/pam_pkcs11/browser/trunk/src/scconf, but that is not suitable here (missing Include directive). Bye