[pacman-dev] PacTrac was: Re: [arch-general] [arch-dev-public] ArchISO FTP Installer - Testers Needed
2008/3/27, Christos Nouskas <nouskas@gmail.com>:
Damir Perisa wrote:
i have a no-optical-drive laptop (non-macs are not able to boot from firewire cdroms) and usually i prepare a image to put on a memory-stick to boot from [1]. since this setting (no cdrom) are getting more common and having a live-linux-system on a usb-key is getting interesting i'm wondering if we should provide also a partition image[2] for such use?
I've been using FaunOS (http://www.faunos.com/) for a couple of months now, and my opinion can only be described as excellent. It's a live archlinux system focused on booting from detachable usb media, fits in a 1GB stick, does a wonderful job in hardware detection (I tested it in 3 different machines), saves all changes back to the usb stick, suspends to usb and it's FAAAAAST! Wherever I can't take my arch-laptop, I take my usb stick!
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 -- Roman Kyrylych (Роман Кирилич)
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? Bye
2008/3/27, Nagy Gabor <ngaba@bibl.u-szeged.hu>:
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 (Роман Кирилич)
Here is a link: http://viewvc.faunos.com/viewvc.cgi/src/pactrac/ License should be GPL2 (like the rest of Faun.
2008/3/27, Nagy Gabor <ngaba@bibl.u-szeged.hu>:
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
matthias@archlinux.de wrote:
2008/3/27, Nagy Gabor <ngaba@bibl.u-szeged.hu>:
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.
PacTrac is based on the Andy Robert's Jacman. It is GPL v2. Along with other FaunOS source code, PacTrac source code is available from the FaunOS svn repos at http://svn.faunos.com. You can browse it here: http://viewvc.faunos.com/viewvc.cgi/src/pactrac/trunk/ And the PKGBUILD is available here: http://viewvc.faunos.com/viewvc.cgi/pkgbuilds/extra/pactrac/trunk/ 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. 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. Currently I am keeping a close eye on Shaman, http://shaman.iskrembilen.com Very promising but hasn't stablized yet. Regards, Raymano On Thu, Mar 27, 2008 at 7:20 AM, Xavier <shiningxc@gmail.com> wrote:
matthias@archlinux.de wrote:
2008/3/27, Nagy Gabor <ngaba@bibl.u-szeged.hu>:
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.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
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.
On Thu, Mar 27, 2008 at 9:16 AM, Xavier <shiningxc@gmail.com> wrote:
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 ? :)
Or, better yet, document the API, or help us document it?
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
On Thu, Mar 27, 2008 at 02:20:57PM +0100, Xavier <shiningxc@gmail.com> wrote:
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.
we use libpacman is several places: * splitting the repo to several cds (if foo depends on bar, then foo can't be on cd1 if bar is on cd2) * testsuite (for exaple for checking if foo depends on bar, then bar should be in the repo as well) * gfpm probably at other places as well. and this would not be possible if originally there would be no libalpm. so don't think it was a useless work! :)
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
participants (7)
-
Aaron Griffin
-
matthias＠archlinux.de
-
Miklos Vajna
-
Nagy Gabor
-
Raymano Garibaldi
-
Roman Kyrylych
-
Xavier