March 2008 - Pacman-dev - lists.archlinux.org

[pacman-dev] Libalpm direction and usage by others
by Dan McGee 29 Mar '08

29 Mar '08

On Thu, Mar 27, 2008 at 10:42 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Thu, Mar 27, 2008 at 9:16 AM, Xavier <shiningxc(a)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? It is clear to us on the list that no one has really latched on to using libalpm. To be honest, I don't blame anyone for this, as the interface seems to have been drawn at a bad level, and calling things like alpm_trans_commit() after 6 other functions and setting flags right just isn't intuitive. So, what does this lead us to? 1. Document the existing interface better. Although it isn't perfect, we aren't going to get frontend clients without documentation. As all of us working on the one client that does use libalpm (pacman) have clearly not felt a need for further documentation, this is really going to have to be spearheaded by someone outside of our current "normal" developers. Anyone want to step up? 2. Frontend developers need to speak up and get ideas on this list. I constantly see rhetoric like the above, where people say the current API is not very good, but they have not done a damn thing to change it. We can't read minds here, and we also aren't going to just change things on our own. So speak up people! If we get some good discussion going, we could really make changes to the API to make it usable. 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". 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. 4. Switch to something like python. I'm resistant to this idea. Although I think scripting languages like this have great benefits, I don't think pacman needs most of them. Having a package manager that always works is important to me, and part of me just thinks a low-level compiled language is the right thing for a system tool. Of the four options above, I have been pushing 1 and/or 2 for a long time. However, I am starting to lean toward option 3. I'd love to hear your thoughts on this. -Dan

7 9

[pacman-dev] [PATCH] Use pkgcache instead of db_scan in remove.c
by Nagy Gabor 29 Mar '08

29 Mar '08

From 51abd287f9c40499f6985c3266441780a04c298c Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Fri, 28 Mar 2008 17:06:49 +0100 Subject: [PATCH] Use pkgcache instead of db_scan in remove.c This should be a notable speed-up (apart from kernel cache). Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/deps.c | 2 +- lib/libalpm/remove.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 1eebca3..2d92179 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -506,7 +506,7 @@ void _alpm_recursedeps(pmdb_t *db, alpm_list_t *targs, int include_explicit) && can_remove_package(db, deppkg, targs, include_explicit)) { _alpm_log(PM_LOG_DEBUG, "adding '%s' to the targets\n", alpm_pkg_get_name(deppkg)); - /* add it to the target list */ + /* add it to the target list */ targs = alpm_list_add(targs, _alpm_pkg_dup(deppkg)); } } diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c index dfdcabe..8d83294 100644 --- a/lib/libalpm/remove.c +++ b/lib/libalpm/remove.c @@ -61,7 +61,7 @@ int _alpm_remove_loadtarget(pmtrans_t *trans, pmdb_t *db, char *name) RET_ERR(PM_ERR_TRANS_DUP_TARGET, -1); } - if((info = _alpm_db_scan(db, name)) == NULL) { + if((info = _alpm_db_get_pkgfromcache(db, name)) == NULL) { _alpm_log(PM_LOG_DEBUG, "could not find %s in database\n", name); RET_ERR(PM_ERR_PKG_NOT_FOUND, -1); } @@ -77,7 +77,7 @@ int _alpm_remove_loadtarget(pmtrans_t *trans, pmdb_t *db, char *name) } _alpm_log(PM_LOG_DEBUG, "adding %s in the targets list\n", info->name); - trans->packages = alpm_list_add(trans->packages, info); + trans->packages = alpm_list_add(trans->packages, _alpm_pkg_dup(info)); return(0); } @@ -107,12 +107,12 @@ int _alpm_remove_prepare(pmtrans_t *trans, pmdb_t *db, alpm_list_t **data) alpm_list_t *i; for(i = lp; i; i = i->next) { pmdepmissing_t *miss = (pmdepmissing_t *)i->data; - pmpkg_t *info = _alpm_db_scan(db, miss->target); + pmpkg_t *info = _alpm_db_get_pkgfromcache(db, miss->target); if(info) { if(!_alpm_pkg_find(alpm_pkg_get_name(info), trans->packages)) { _alpm_log(PM_LOG_DEBUG, "pulling %s in the targets list\n", alpm_pkg_get_name(info)); - trans->packages = alpm_list_add(trans->packages, info); + trans->packages = alpm_list_add(trans->packages, _alpm_pkg_dup(info)); } } else { _alpm_log(PM_LOG_ERROR, _("could not find %s in database -- skipping\n"), -- 1.5.3.8

1 1

[pacman-dev] [PATCH] Keep pkgcaches and dbs in sync
by Nagy Gabor 28 Mar '08

28 Mar '08

From db6d957330d03f3c369001c0fb91e6dec8d5651d Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Thu, 27 Mar 2008 18:55:52 +0100 Subject: [PATCH] Keep pkgcaches and dbs in sync Ref.: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009429.html http://bugs.frugalware.org/index.php?do=details&task_id=2533 This patch based on the work of Vajna Miklos (vmiklos) from pacman-g2. It's time to fix this issue, since we have upcoming GUIs. Briefly, the problem is that pkgcache can become outdated. The trivial fix would be: reload pkgcache immediately after db lock. We follow a more sophisticated approach to minimize overhead: 1. Each dbs on HDD have a "fingerprint": .lastupdate (patch extends this to localdb too) 2. After pkgcache load this fingerprint is recorded to the new fingerprint field of pmdb_t 3. New _alpm_db_refrech_pkgcache was introduced to reload cache, if it outdated. (Note: fingerprint treats transaction atomic.) Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/cache.c | 17 +++++++++++++++++ lib/libalpm/cache.h | 1 + lib/libalpm/db.h | 1 + lib/libalpm/trans.c | 11 +++++++++++ 4 files changed, 30 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/cache.c b/lib/libalpm/cache.c index 7fa2405..8922dca 100644 --- a/lib/libalpm/cache.c +++ b/lib/libalpm/cache.c @@ -67,6 +67,7 @@ int _alpm_db_load_pkgcache(pmdb_t *db) } db->pkgcache = alpm_list_msort(db->pkgcache, count, _alpm_pkg_cmp); + db->fingerprint = _alpm_db_getlastupdate(db); return(0); } @@ -90,6 +91,22 @@ void _alpm_db_free_pkgcache(pmdb_t *db) } } +/* Reload pkgcache if it is outdated + */ +int _alpm_db_refresh_pkgcache(pmdb_t *db) { + ALPM_LOG_FUNC; + + if(db == NULL) { + return(-1); + } + + if(!db->pkgcache || (db->fingerprint != _alpm_db_getlastupdate(db))) { + return(_alpm_db_load_pkgcache(db)); + } + + return(0); +} + alpm_list_t *_alpm_db_get_pkgcache(pmdb_t *db) { ALPM_LOG_FUNC; diff --git a/lib/libalpm/cache.h b/lib/libalpm/cache.h index 915896e..4569b70 100644 --- a/lib/libalpm/cache.h +++ b/lib/libalpm/cache.h @@ -27,6 +27,7 @@ /* packages */ int _alpm_db_load_pkgcache(pmdb_t *db); void _alpm_db_free_pkgcache(pmdb_t *db); +int _alpm_db_refresh_pkgcache(pmdb_t *db); int _alpm_db_add_pkgincache(pmdb_t *db, pmpkg_t *pkg); int _alpm_db_remove_pkgfromcache(pmdb_t *db, pmpkg_t *pkg); alpm_list_t *_alpm_db_get_pkgcache(pmdb_t *db); diff --git a/lib/libalpm/db.h b/lib/libalpm/db.h index 8c8c9bd..cd362d5 100644 --- a/lib/libalpm/db.h +++ b/lib/libalpm/db.h @@ -45,6 +45,7 @@ struct __pmdb_t { alpm_list_t *pkgcache; alpm_list_t *grpcache; alpm_list_t *servers; + time_t fingerprint; /* of pkgcache */ }; /* db.c, database general calls */ diff --git a/lib/libalpm/trans.c b/lib/libalpm/trans.c index 3edbbac..f425147 100644 --- a/lib/libalpm/trans.c +++ b/lib/libalpm/trans.c @@ -65,6 +65,7 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, alpm_trans_cb_progress progress) { ALPM_LOG_FUNC; + alpm_list_t *i; /* Sanity checks */ ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1)); @@ -77,6 +78,12 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, RET_ERR(PM_ERR_HANDLE_LOCK, -1); } + /* ensure dbs and pkgcaches are in sync */ + _alpm_db_refresh_pkgcache(handle->db_local); + for(i = handle->dbs_sync; i; i = i->next) { + _alpm_db_refresh_pkgcache(i->data); + } + handle->trans = _alpm_trans_new(); if(handle->trans == NULL) { RET_ERR(PM_ERR_MEMORY, -1); @@ -203,6 +210,10 @@ int SYMEXPORT alpm_trans_release() _alpm_trans_free(trans); handle->trans = NULL; + time_t fingerprint = time(NULL); + _alpm_db_setlastupdate(handle->db_local, fingerprint); + handle->db_local->fingerprint = fingerprint; + /* unlock db */ if(handle->lckfd != -1) { close(handle->lckfd); -- 1.5.3.8

1 3

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-98-gd140b44
by Dan McGee 28 Mar '08

28 Mar '08

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via d140b440a86cc55bec6086e8d4a4d2606ebb6d1e (commit) via f8c737d3b6b28373a69d5979a4ba2e31b77baa62 (commit) via 1dfd841e40344ff401e0d9e8d61b55cb64b2681f (commit) from 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit d140b440a86cc55bec6086e8d4a4d2606ebb6d1e Author: Dan McGee <dan(a)archlinux.org> Date: Wed Mar 26 21:26:43 2008 -0500 Read .PKGINFO directly from package file With the addition of the archive_fgets() function, we can now skip the temp file usage in pkg_load/parse_descfile that was not needed. This has a nice benefit of probably being both faster, reducing code, and getting rid of "expensive" file operations. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f8c737d3b6b28373a69d5979a4ba2e31b77baa62 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Mar 25 21:23:14 2008 -0500 Add an archive_fgets() function This crude function allows reading from an archive on a line-by-line basis similar to the familiar fgets() call on a FILE stream. This is the first step in being able to read DB entries straight from an archive. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 1dfd841e40344ff401e0d9e8d61b55cb64b2681f Author: Dan McGee <dan(a)archlinux.org> Date: Wed Mar 26 20:19:44 2008 -0500 Make db->treename a pointer I really don't think we need statically allocated strings here. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/db.c | 4 +- lib/libalpm/db.h | 2 +- lib/libalpm/package.c | 61 +++++++++---------------------------------------- lib/libalpm/util.c | 29 +++++++++++++++++++++++ lib/libalpm/util.h | 2 + 5 files changed, 45 insertions(+), 53 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 28 Mar '08

28 Mar '08

Ops, I re-read it badly, just ignore my last post, I'm a bit tired... Dario

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 28 Mar '08

28 Mar '08

sorry, I think alpm is totally shit was I don't think alpm is totally shit but I think you got that ^^ Dario

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 28 Mar '08

28 Mar '08

> > Well, I am not sure why you felt offended, Dan didn't mean it that way. > I'm not offended, I just feared that libalpm could disappear and all my efforts wasted. > What you did is indeed great, that would be the first real frontend > using libalpm. (well there is also gfpm using frugalware's libpacman, > but I don't think anyone really ported it to libalpm, at least it's not > uptodate). > Thanks a lot :) > But actually, that's the point, you are the only one, while there are > countless of others tools simply calling pacman, or parsing the stuff > themselves. > Exactly. This is the point. Experience teaches me one thing: people stick to habits. I think the only reason I developed Shaman this way is because I'm new to Arch, and alpm already existed. If Shaman previously used pacman and worked, I don't think I'd have taken the risk to port it to alpm. Or maybe, people still fear libalpm. Maybe they don't even know what it does, why it exists. Maybe they think it's a bit harder, well it is. But there is a huge difference. > Still, your project should give us a better idea about the quality and > usefulness of libalpm, and I hope that you will have concrete > suggestions for improving libalpm and making it more friendly to use :) That's why I showed you the link here. It was not a "oh, look, I'm so good", because I consider myself a really worse coder than the ones who develop pacman/alpm, and I'm speaking for real. I'm not talking about who can code better, I'm talking about ideas, and not coding. Sorry to say that, but Xavier, it was you who answered my mail. It was you who answered Lukas when he asked about alpm version. It is you that says that doors are open, and I really appreciate that. The point is that, even here, you're the only one. Because nobody else replied to that mail (or at least, replied to the point of that mail) but you. I don't pretend to be the solution of all the problems, and maybe some of my ideas are wrong, but developing Shaman helped me seeing a lot of flaws in alpm. A lot of unsafe behaviours. And this doesn't mean that I think alpm is totally shit. Do you think I'd have developed something upon pure shit? I'm not so masochist. Ok, sometimes I said it was, but it was frustration that made me speak. And I DO think that libalpm is worth the effort. Shaman is the living demostration that alpm works, that alpm is useful, both to developers and users, even if it has some design flaws. And I don't want it to die, because it doesn't have to. Alpm is more stable/efficient than apt/dpkg in my opinion, even if some bad choices in DB handling make it slower in searching and loading the database, but I've seen nothing handling package processing that fast, and that's the reason why I bet on Shaman, and I'd still make the same choice now. But I do believe that libalpm can be even faster. That something can be improved to make it even better. And that should be the question and the direction, being honest on ourself. And not listening to trolls who just say some banal/stupid stuff about SQLite and such, not saying "complicated and not worth it" when you don't even know what that thing could mean. I hope that was a bit clearer. Cheers Dario

1 0

Re: [pacman-dev] Libalpm direction and usage by others
by Dario Freddi 28 Mar '08

28 Mar '08

> > It is clear to us on the list that no one has really latched on to > using libalpm. Don't agree > To be honest, I don't blame anyone for this, as the > interface seems to have been drawn at a bad level, and calling things > like alpm_trans_commit() after 6 other functions and setting flags > right just isn't intuitive. > Agreed. > So, what does this lead us to? > 1. Document the existing interface better. Although it isn't perfect, > we aren't going to get frontend clients without documentation. As all > of us working on the one client that does use libalpm (pacman) have > clearly not felt a need for further documentation, this is really > going to have to be spearheaded by someone outside of our current > "normal" developers. Anyone want to step up? > Stop on that. When I started my work, I had only this (http://code.toofishes.net/pacman/doc/index.html) and the code. You know what? That was enough, and I didn't EVER complain about it. A competent programmer knows that, even if he had the best documentation around, sooner or later he will have to see the code to understand how things **really** work out. Sure, an improvement could be good, but don't forget that something is already out there. > 2. Frontend developers need to speak up and get ideas on this list. I > constantly see rhetoric like the above, where people say the current > API is not very good, but they have not done a damn thing to change > it. We can't read minds here, and we also aren't going to just change > things on our own. So speak up people! If we get some good discussion > going, we could really make changes to the API to make it usable. > I once sent a mail, I proposed some ideas, I got one (1) answer, and... what? I proposed to abstract the backend, some real things, I'm writing a whole paper on that, I'm ready to show you something REAL, some real ideas, some people who really want to do that but... where is the list? Why just shining answered to my mail? Why didn't anybody else step up and said: "Ok good" or "No, sucks". You wanna see some code? Some efforts? Is that one enough? http://shaman.iskrembilen.com/trac.cgi/wiki I wrapped libalpm around a C++ class and guess what? It works. It still has issues, but shaman works, and while I'm writing, a lot of people are using it, even if I still haven't put it on Arch bbs, since I want it to reach a real beta stage (where beta means usable, feature full, with some minor stuff, something we've almost achieved). Will somebody listen to that now? Will somebody say that alpm, library or not, needs improvements and not in the code, in the basic ideas around it? Will somebody finally admit that it's time to hear other voices? In my opinion, simplicity is also making life easier. Having a choice between db frontends is simple, since everyone can write its backend, and it gives the user freedom to use whatever it wants. > 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking > "but that would be a step backwards!". 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. > 4. Switch to something like python. I'm resistant to this idea. > Although I think scripting languages like this have great benefits, I > don't think pacman needs most of them. Having a package manager that > always works is important to me, and part of me just thinks a > low-level compiled language is the right thing for a system tool. > Python or not, don't even think on that. First of all, all our efforts into shaman would be a waste. Secondly, you close every door through a different frontend than pacman, and I don't really think this is really the Arch way. > Of the four options above, I have been pushing 1 and/or 2 for a long > time. However, I am starting to lean toward option 3. I'd love to hear > your thoughts on this. > This is my thought. Out there, a lot of people have great ideas about pacman/alpm, but nobody here ever seemed to have listened to them. You asked for some code, I brought you Shaman. I'm ready to get up with some well documented ideas, but I don't know if there is the right attitude to accept other point of views. And I'm not talking about the SQLite stuff - I hate SQLite, and it sucks for a package manager. But honestly... would you give alpm the fault for all those void*s, for all that useless package structs, and whatever else? There is someone who latched over libalpm, and it's me. I believed in it, even a lot of stuff was wrong, and the result is Shaman. You can say you don't like it, ok, that's fine. What you can't say is that it is a real step forward compared to gtkpacman & friends, that used pacman instead (I'm not saying they're bad, I'm just showing the difference in wrapping pacman and libalpm, gtkpacman still remains a piece of software IMHO) > -Dan > Didn't mean to offend anyone, sorry if I did. Cheers Dario

2 1

[pacman-dev] PacTrac was: Re: [arch-general] [arch-dev-public] ArchISO FTP Installer - Testers Needed
by Roman Kyrylych 28 Mar '08

28 Mar '08

2008/3/27, Christos Nouskas <nouskas(a)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 (Роман Кирилич)

7 10

Re: [pacman-dev] [arch-general] lzma compression tests
by Dan McGee 25 Mar '08

25 Mar '08

CCing to pacman-dev. On Mon, Mar 24, 2008 at 3:25 PM, Jan de Groot <jan(a)jgc.homeip.net> wrote: > > On Mon, 2008-03-24 at 14:43 -0500, Dan McGee wrote: > > On Mon, Mar 24, 2008 at 2:24 PM, Mark Constable <markc(a)renta.net> wrote: > > > FWIW, possibly worth considering adding lzma to pacman... > > > > > > http://www.kdedevelopers.org/node/3326 > > > > > > --markc > > > > Interesting. You may want ot take this to the pacman-dev ML. A good > > "real-world" look might be grabbing the openoffice package and > > uncompressing it to a folder, and then run the following tests: > > > > bsdtar czf package (gzip) > > bsdtar cjf package (bzip2) > > <lzma creation of package> > > > > and then the similar unzip costs, along with the size of the original > > folder structure (unzipped package) vs. their zipped counterparts. > > > > -Dan > > > > I tested with OpenOffice.org, here are the results. Note that I had to > use a weird construction to compress lzma files, as tar has no native > support yet (1.19.90 has official lzma support I read on some debian > mailinglist). > > Compression times take a huge increase in time, but in case of > openoffice, I think 30 seconds extra compression time will save on much > more upload time, as the resulting package would be 20MB smaller. > For the end user, it depends on their connection. Most users will have > <10Mb/s connections and will see a positive change in installation > speed: 10 seconds extra for extraction, 20 seconds less for downloading > the package. > > [jan@server ~]$ time bsdtar czf oo.tar.gz oo/ > real 0m24.244s > user 0m23.882s > sys 0m0.360s > > [jan@server ~]$ time bsdtar cjf oo.tar.bz2 oo/ > real 0m55.812s > user 0m55.310s > sys 0m0.377s > > [jan@server ~]$ time tar c oo | lzma -2 > oo.tar.lzma > real 0m55.070s > user 0m54.583s > sys 0m0.740s > > [jan@server ~]$ time tar c oo | lzma -1 > oo.tar.lzma1 > real 0m38.995s > user 0m38.737s > sys 0m0.503s > > [jan@server ~]$ du -h oo.tar.* > 108M oo.tar.bz2 > 115M oo.tar.gz > 95M oo.tar.lzma > 101M oo.tar.lzma1 > > [jan@server u]$ time tar zxf ../oo.tar.gz > real 0m3.570s > user 0m3.383s > sys 0m0.967s > > [jan@server u]$ time tar jxf ../oo.tar.bz2 > real 0m19.431s > user 0m17.826s > sys 0m1.367s > > [jan@server u]$ time tar --use-compress-program=lzma -xf ../oo.tar.lzma > real 0m13.211s > user 0m12.306s > sys 0m1.117s > (the lzma1 archive gives equal timings) Did you try with bsdtar on the extraction as well? That may make a difference over (gnu)tar. Should be: time bsdtar xf ../oo.tar.gz time bsdtar xf ../oo.tar.bz2 time bsdtar --use-compress-program=lzma -xf ../oo.tar.lzma -Dan

3 2