You are not logged in.
Hello everyone,
for those who don't know me: I'm a former TU and long time yaourt user.
Unfortunately yaourt doesn't seem to be maintained anymore and has quite some problems (e.g. UI nits, security issues, huge shell codebase).
But since yaourt's interface is so great I have decided to code up an alternative called Paktahn (after a ship type from Wing Commander).
For now it's just a development preview for interested people. It might toast your cat, although it's not designed to do that.
Right now it also offers just the most convenient (for me) two features of yaourt: the -S mode where you can install a package from repos or AUR and the mode with just a plain argument that let's you search in repos and AUR and then interactively install one or more packages from the results.
This doesn't mean that there won't be support for other things, but yaourt's functionality has grown huge and one can't implement all that stuff alone in a few days.
Development site and repository at Gitorious: http://gitorious.org/paktahn
A binary package can be downloaded here: http://viridian-project.de/~sky/paktahn … pkg.tar.gz
It's a clean package that I personally vouch for.
Building from source is a bit more elaborate since you need to download the Common Lisp deps on your own, e.g. using clbuild. Contact me if you want to help and hit a wall. In the future this will be solved with either proper packages or a script that automates the process. Like I said, this is mainly a preview.
Contributions, bug reports, comments and praise are all welcome, as are donations since I'm an independent software developer.
Have a nice day,
Leslie
Offline
How are you compiling it? ECL?
Edit: I've checked the source out, you're using SBCL. Maybe ECL is a better choice, as it generates smaller binary files.
Last edited by andre.ramaciotti (2009-08-09 17:17:13)
(lambda ())
Offline
Hello.
I fond your project quite interesting, as yaourt seems abandoned and still has some stuff to be improved.
Are you going to do this in the future?
- Able to use aria2c and other like in powerpill wrapper.
- Intelligent use of mirrors, including not only speed comparison but also updated comparison.
- Functionality like pacman-cage.
- No need to manually modify dates from PKBBUILDs.
- Emacs friendly.
- Build packages from AUR or ABS for other platforms (crosscompiling) and to act as a mirror or "package build server" for them.
What about a tracker and adding feature requests?
What's the reason for choosing clisp instead more popular languages like Python C or C++? Maybe this limits the amount of future possible develepers contributing to the project.
Regards.
Offline
What's the reason for choosing clisp instead more popular languages like Python C or C++? Maybe this limits the amount of future possible develepers contributing to the project.
it certainly will, but on the other hand it attracts emacs users ^^
Offline
It seems that the users of The All Perfect and Mighty Emacs are a minority here.
I'm a lisp lover, but I agree that another language such as Python would be better suited for this. C would be overkill.
(lambda ())
Offline
I'm sure dejari had his reasons for writing in lisp. Personally I'm just glad that progress is being made to replace yaourt, since I rely so heavily on it.
Offline
I would like to please ask that you add the feature that tupac's -G implements, which downloads the PKGBUILD and such from the Internet, making ABS mostly unnecessary. It also works for the AUR.
Thanks for creating this!
Offline
looking forward to a final release.
Offline
WTB a PKGBUILD for this or at least a x86_64 binary.
Offline
WTB a PKGBUILD for this or at least a x86_64 binary.
Clone that git repo and you'll find PKGBUILD there
Sincerely,
Gour
Offline
Hi!
Building from source is a bit more elaborate since you need to download the Common Lisp deps on your own, e.g. using clbuild. Contact me if you want to help and hit a wall.
Cloned the repo, produced tarball, adjusted md5sum, downloaded sbcl and tried to build with:
[gour@gaura-nitai paktahn] makepkg -cf
==> Making package: paktahn 0.8-1 x86_64 (Mon Aug 10 07:51:15 CEST 2009)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
-> Found paktahn-0.8.tar.bz2 in build dir
==> Validating source files with md5sums...
paktahn-0.8.tar.bz2 ... Passed
==> Extracting Sources...
-> bsdtar -x -f "paktahn-0.8.tar.bz2"
==> Removing existing pkg/ directory...
==> Entering fakeroot environment...
==> Starting build()...
; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd into
; #<PACKAGE "ASDF1">
; registering #<SYSTEM SB-GROVEL {100304AFC1}> as SB-GROVEL
debugger invoked on a SB-INT:EXTENSION-FAILURE in thread #<THREAD "initial thread" RUNNING {10028E6051}>:
Don't know how to REQUIRE CL-JSON.
See also:
The SBCL Manual, Variable *MODULE-PROVIDER-FUNCTIONS*
The SBCL Manual, Function REQUIRE
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore runtime option --load "main.lisp".
1: [ABORT ] Skip rest of --eval and --load options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
(SB-IMPL::REQUIRE-ERROR "Don't know how to ~S ~A.")[:EXTERNAL]
but CONTINUE does not bring me further.
Don't have much experience with CL except playing a bit with it while building xindy.
Any idea?
Sincerely,
Gour
Offline
Thanks everyone for the questions and comments.
Replies:
Edit: I've checked the source out, you're using SBCL. Maybe ECL is a better choice, as it generates smaller binary files.
I agree that ECL will be an interesting target, but for now the objective is maximum development speed and maturity of the underlying Lisp implementation so I'm using SBCL. Feel free to try your hands at an ECL port right away though, the source of Paktahn is written with portability in mind.
- Able to use aria2c and other like in powerpill wrapper.
You mean alternative download managers? Seems like an easy thing to add. But making a full Pacman wrapper is not a priority right now, and I'm not sure it should be done at all. However letting the user specify his "pacman" (wrapper) makes sense. Is that what you meant?
- Intelligent use of mirrors, including not only speed comparison but also updated comparison.
This looks like a job for a separate tool...
- Functionality like pacman-cage.
Probably out of scope. Adding caching of the database inside Paktahn would be possible (and I'm going to look at this in the future), but optimizing it in a form that Pacman/libalpm itself can make use of it is better left in a separate tool -- or integrated into Pacman itself.
- No need to manually modify dates from PKBBUILDs.
What dates do you mean? How should it be automated?
- Emacs friendly.
I don't get this. Do you want a pkgbuild-mode for Emacs? In this case, wait no further: http://aur.archlinux.org/packages.php?ID=2343
Or do you mean using Emacs as an editor to review and edit the PKGBUILD? Both Paktahn (in principle) and yaourt support this via the EDITOR environment variable.
- Build packages from AUR or ABS for other platforms (crosscompiling) and to act as a mirror or "package build server" for them.
Again this would better be part of a separate tool. Wasn't there something about Strawberry or another fruit-named piece of software that would do this?
What about a tracker and adding feature requests?
I'll probably set one up later (or someone else might do). For the moment this thread is enough.
What's the reason for choosing clisp instead more popular languages like Python C or C++?
It's effective and fun. This is largely a hobby project for me (as in, I don't expect that many people will pay a dime for it) so fun is important. About Python: Common Lisp is similar. With some effort a Python programmer can hack it too. About C/C++: too many things to care about. I know them both but C is too minimalistic for this project, and we all know what sort of thing C++ is (look here in case you don't: http://yosefk.com/c++fqa/ ).
Maybe this limits the amount of future possible develepers contributing to the project.
Maybe, but then again I'm not sure yaourt did receive that many outside contributions...
I would like to please ask that you add the feature that tupac's -G implements, which downloads the PKGBUILD and such from the Internet, making ABS mostly unnecessary. It also works for the AUR.
You mean pointing it directly at a PKGBUILD uri? Nice. We could take a look at the uri and depending on whether it's a tarball (PKGBUILD and support files) or just a single PKGBUILD take action. I'm going to put this high up in the queue.
Don't know how to REQUIRE CL-JSON.
Yeah, you don't have the dependencies installed. Bad news: Common Lisp packages in ArchLinux are rare (casts an envious glance at the Haskell guys) so until someone comes along and packages them in a good manner you'll have to deal with that yourself. But like I wrote in the OP you could also wait until I write a small script that downloads the deps for you.
Good news: clbuild makes it simple. If you want to hack on it yourself try this:
1. download clbuild from http://common-lisp.net/project/clbuild/
2. add the following lines to the file wnpp-projects:
getopt get_tarball http://files.b9.com/getopt/getopt-latest.tar.gz
py-configparser get_tarball http://common-lisp.net/project/py-configparser/releases/py-configparser-1.0.3.tar.gz
3. Install the dependencies:
sh clbuild check
sh clbuild install cl-json drakma cffi alexandria metatilities getopt split-sequence cl-ppcre py-configparser parse-number
4. Put this line into your ~/.sbclrc:
(push "/path/to/clbuild/systems/" asdf:*central-registry*)
Mind the trailing "systems" and slash.
This recipe is untested but we'll see soon enough whether it will work for you.
Leslie
Last edited by dejari (2009-08-10 09:54:06)
Offline
Bad news: Common Lisp packages in ArchLinux are rare (casts an envious glance at the Haskell guys) so until someone comes along and packages them in a good manner you'll have to deal with that yourself.
Why not Haskell then?
Sincerely,
Gour
Offline
dejari wrote:Bad news: Common Lisp packages in ArchLinux are rare (casts an envious glance at the Haskell guys) so until someone comes along and packages them in a good manner you'll have to deal with that yourself.
Why not Haskell then?
Haskell's nice, but CL is more my cup of tea. Besides, the number of packages available in your favorite distro doesn't seem like a good criterion.
Offline
dejari wrote:Bad news: Common Lisp packages in ArchLinux are rare (casts an envious glance at the Haskell guys) so until someone comes along and packages them in a good manner you'll have to deal with that yourself.
Why not Haskell then?
Sincerely,
Gour
Haskell is cool . But i still don't know why u would use lisp for an AUR program. Bash/python/ruby is imao much easier to understand en wouldnt need so much deps. Look at rson's slurpy it uses -json wich makes searching incredible fast
But if you want to do it in Lisp, just do it . You could also add some lisp packages to AUR
Offline
Haskell's nice, but CL is more my cup of tea. Besides, the number of packages available in your favorite distro doesn't seem like a good criterion.
I was thinking more about having all the deps readily available, than the sheer numner of packages in the distro.
It's kind of paradox to have pacman wrapper without having all the deps.
Sincerely,
Gour
Offline
Haskell is cool . But i still don't know why u would use lisp for an AUR program. Bash/python/ruby is imao much easier to understand
I understand Lisp quite well, but YMMV.
en wouldnt need so much deps.
They would actually require more runtime dependencies.
Look at rson's slurpy it uses -json wich makes searching incredible fast
Paktahn uses CL-JSON which yields decent speed. I'm not sure how those two would compare.
But if you want to do it in Lisp, just do it .
Thanks!
You could also add some lisp packages to AUR
Sorry, even Paktahn alone is stretching my time...
Offline
I was thinking more about having all the deps readily available, than the sheer numner of packages in the distro.
Right, but it's not that hard even without packages to install the deps. In Ruby you'd probably have to install some additional gems, in Perl some stuff from CPAN that isn't packages yet. clbuild is similar.
It's kind of paradox to have pacman wrapper without having all the deps.
It doesn't matter if you use the binary package, all those deps are just makedepends.
Offline
It doesn't matter if you use the binary package, all those deps are just makedepends.
I'm on x86_64
Offline
Sorry! But right now I'm making a tarball with all the deps that you can download.
Offline
Here is the tarball: http://viridian-project.de/~sky/paktahn-makedeps.tbz2
Unpack this somewhere (let's say in /var/tmp), then put this line into your ~/.sbclrc:
(push "/var/tmp/clbuild.paktahn/systems/" asdf:*central-registry*)
This should do the trick.
Be sure to do a fresh pull of the Git repo, I've pushed some new changes to it this morning.
Also if you want to interact with Pacman and use your $EDITOR to edit PKGBUILDs you need a patched version of SBCL (the patch is included in the repo). But Paktahn should work without that (it should just use Pacman in --noconfirm mode and cat instead of an interactive editor).
Offline
Here is the tarball: http://viridian-project.de/~sky/paktahn-makedeps.tbz2
It's nice to see that some stuff is under darcs.
Unpack this somewhere (let's say in /var/tmp), then put this line into your ~/.sbclrc:
(push "/var/tmp/clbuild.paktahn/systems/" asdf:*central-registry*)
This should do the trick.
Here is the result:
==> Starting build()...
debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread #<THREAD "initial thread" RUNNING {10028E6051}>:
SB-INT:SIMPLE-READER-PACKAGE-ERROR at 65 (line 1, column 65) on #<SB-SYS:FD-STREAM for "file /home/gour/.sbclrc" {10028E95C1}>:
package "ASDF" not found
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore error and continue processing userinit file "/home/gour/.sbclrc".
1: [ABORT ] Skip rest of userinit file "/home/gour/.sbclrc".
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
(SB-IMPL::READ-TOKEN
#<SB-SYS:FD-STREAM for "file /home/gour/.sbclrc" {10028E95C1}>
#\a)
Sincerely,
Gour
Offline
Ah, a little oversight. Sorry about that. You need an additional line in ~/.sbclrc.
The whole file:
(require :asdf)
(push "/var/tmp/clbuild.paktahn/systems/" asdf:*central-registry*)
Offline
Ah, a little oversight. Sorry about that. You need an additional line in ~/.sbclrc.
The whole file:
(require :asdf) (push "/var/tmp/clbuild.paktahn/systems/" asdf:*central-registry*)
Thanks. It looks better now, but still:
...
; compiling (DEFUN WRITE-STREAM ...)
; /var/tmp/clbuild.paktahn/source/py-configparser/parser.fasl written
; compilation finished in 0:00:00.892
debugger invoked on a PY-CONFIGPARSER:PARSING-ERROR in thread #<THREAD "initial thread" RUNNING {10028E6051}>:
Character R found, but one of (: =) expected. at line 37
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore runtime option --load "main.lisp".
1: [ABORT ] Skip rest of --eval and --load options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
(PY-CONFIGPARSER::EXPECT-ONE-OF
#<SB-SYS:FD-STREAM for "file /etc/pacman.conf" {10036125B1}>
(#\: #\=))[:EXTERNAL]
Any idea?
Sincerely,
Gour
Offline
Please post your pacman.conf.
Offline