You are not logged in.
Pages: 1
I'm working on a pacman frontend, actually not really a frontend, it's a graphical reimplentation of pacman in pygtk. Anyways this is what the ui looks like.
Anyone have any comments suggestions? (Except for "Awwrgh! Not another pygtk pacman app!" )
Offline
Well I'd rather stick with my CLI pacman personally, but one thing that would be cool in a pacman GUI would be the ability to pull packages off AUR and build them. Dependancy resolving would be good too, like if a dep is on AUR (in unsupported) then pull that down and build it too. Perhaps if the packages hasn't been marked safe, give the user a warning.
I just know that a lot of newbie will love the fact that pacman has a Synaptic-like GUI but people still get confused by the concept or AUR and how it works, if you could make that seeamless as well you'd be onto a winner I reckon.
Oh, and are you using libpypac or just making it up as you go? Just curious
Offline
Nah I coded the pacman bits myself. Altough some parts of it are directly or indirectly from libpypac.
However the aur thing seems like a good idea, i'll look in to it.
Offline
For that particular feature, you might want to take a look at this thread.
Offline
For that particular feature, you might want to take a look at this thread.
it will inform the user of a safe package and build dependencies, but only those in /var/abs when using --builddeps switch and whatever is in pacman's database for --syncdeps. I didn't implement installing dependencies from aur because I consider it a security risk without being able to see each PKGBUILD first You can, however, do multiple packages from aur (ie. aurbuild -s package anotherpackage another). Each one will bring up the editor menu.
Offline
Ok, the aur thing is pretty much done. Altough it's quite slow and a bit unstable mostly because the lack of standards in AUR. So i'll probably leave this disabled by default and let more advanced users enable it if they want to.
At the moment it only looks for dependencies in regular repos, I'm not sure about if it's a good idea to auto-fetch deps from AUR.
Perhaps I should add the entire PKGBUILD in the info window to enhance security?
preview:
Offline
Ok, the aur thing is pretty much done. Altough it's quite slow and a bit unstable mostly because the lack of standards in AUR. So i'll probably leave this disabled by default and let more advanced users enable it if they want to.
Hmmm, what do you mean by "lack of standards"? as in directory structure? Can you explain better? If there is anything that would make your stuff easier, don't hesitate to suggest things in the bug tracker.. there's a AUR section.
Offline
lunke wrote:Ok, the aur thing is pretty much done. Altough it's quite slow and a bit unstable mostly because the lack of standards in AUR. So i'll probably leave this disabled by default and let more advanced users enable it if they want to.
Hmmm, what do you mean by "lack of standards"? as in directory structure? Can you explain better? If there is anything that would make your stuff easier, don't hesitate to suggest things in the bug tracker.. there's a AUR section.
Ther's already a bug report: http://bugs.archlinux.org/index.php?do=details&id=2803
Offline
Hmmm, what do you mean by "lack of standards"? as in directory structure? Can you explain better? If there is anything that would make your stuff easier, don't hesitate to suggest things in the bug tracker.. there's a AUR section.
Yes mainly the directory structure. It doesn't always match the name in the PKGBUILDS.
Like this one:
http://aur.archlinux.org/packages/aedks … ontroller/
Should probably be changed to:
http://aur.archlinux.org/packages/adeks … ontroller/
Which seems to be the common standard
Offline
phrakture wrote:Hmmm, what do you mean by "lack of standards"? as in directory structure? Can you explain better? If there is anything that would make your stuff easier, don't hesitate to suggest things in the bug tracker.. there's a AUR section.
Yes mainly the directory structure. It doesn't always match the name in the PKGBUILDS.
Like this one:
http://aur.archlinux.org/packages/aedks … ontroller/
Hah, that's also a typo (aedkslet) - the newer packages should conform to this standard (as there is code to verify that it is in $pkgname/$pkgname). These are probably old hold-overs from before that validation was in there.
I will try to get this fixed, though I don't have access to the server (neotuli does!)
Offline
it looks pretty nice,
and i post an update on libpypac here, since i submitted libpypac to gna.org (they haven't responded yet but a message i got said that they should respond before aug30 but ragnarok told me that it could take longer due to vacations) i've been coding my a** off, you can find more information here http://xerxes2.1go.dk/libpypac.htm ,
you guys that wanna join the project will get subversion access to it as soon as it's available,
arch + gentoo + initng + python = enlisy
Offline
A test release is out for those brave enough. Please do read the important stuff on the hompage if you intend to try it.
http://bbs.archlinux.org/viewtopic.php?p=110361#110361
Offline
wow, impressive stuff lunke, you're a very clean coder,
are you using any license for this or could i just copy and paste some stuff i want to move to libpypac?
and if you wanna join libpypac when it's up on gna.org just say so,
arch + gentoo + initng + python = enlisy
Offline
Thanks Hmm license, GPL I guess unless that's a problem?
Offline
libpypac-0.3.x is lgpl so that's not a fair deal,
well we'll see, it's just a few minor things for now,
and if you join libpypac you can fix it yourself, if you're interested it's libpypac-devel that needs the attention,
it's just more work if everyone should code there own complete pacmans instead of using a library,
arch + gentoo + initng + python = enlisy
Offline
What's the diffrence between GPL and LGPL? Or more precice; why won't they mix?
Yeah that's true, one unified library would be nice. I will have a look at libpypac-devel once I get the time.
Offline
*back from a run in the park*
lgpl means that frontends could use whatever license they wish, think of glibc, your c programs could be distributed under whatever license you like,
and if you're interested in libpypac-devel it's lazy-pac-cli-devel that is the manual/frontend,
arch + gentoo + initng + python = enlisy
Offline
Pages: 1