Comments on: Advantage of a Simple “Database” Format

By: diaz

diaz — Wed, 19 Dec 2012 05:18:47 +0000

Wait, what, you comming here and you weren’t saying anything? C’mon. I’ll need to check it out

(I’m not from IST but that doesnt’ matter )

By: Pierre

Pierre — Mon, 17 Dec 2012 04:06:36 +0000

There’s no point in checking local files. If they were tampered with locally, the attacker can modify the live system too. You only need to check at least once after downloading (or during, as one might argue).

By: Guilherme de Sousa

Guilherme de Sousa — Mon, 17 Dec 2012 02:03:13 +0000

Just try to put some sense into the non linux crowd

By: Allan

Allan — Sun, 16 Dec 2012 23:53:05 +0000

Yay – it has been announced! I will have to figure out what I am talking about…

By: Allan

Allan — Sun, 16 Dec 2012 23:52:22 +0000

Hmm… I seem to remember a patch that performed complete conflict checking before aborting. So I would guess that improvement is going to be in pacman-4.1.

As for not rechecking the checksums, I’d say that is never going to happen. We would have to store a list of package files and the and the database they were checked with and then verify those files have not been tampered with in the mean time… which brings us back to checking their integrity.

By: Guilherme de Sousa

Guilherme de Sousa — Sun, 16 Dec 2012 23:31:19 +0000

I was reading this post a few hours ago, and now I’ve just received the good news that you will be attending a conference in my university (Instituto Superior Técnico, Lisbon, Portugal) in next February. Will definitely be there to ear what you have to say! Tks!

Best regards,

Guilherme

By: ben

ben — Sun, 16 Dec 2012 20:06:49 +0000

Rather that trying to speed up pacman’s database, it would help much more to streamline it’s UI…

If I do a full package update after I haven’t done one in a while, I sometimes get into the following situation:

1) After clicking “y” lots of times (“do you really want to replace X with Y”, etc.), and downloading all packages, pacman takes a lot of time to do the “checking package integrity and file conflicts” step. After a while it finds a conflict, and aborts with and error.
2) I manually fix the file conflict (usually caused by an AUR package).
3) I have to click “y” lots of times again, and again wait a long time while the “checking package integrity and file conflicts” is executed again from the beginning. It finds second file conflict, and aborts again.
4) I manually fix the second file conflict.
5) …and so on…

This could be streamlined:
a) Make it list all file conflicts in one go, so you only have to re-run it once (at the most).
b) If package integrity has already been checked, don’t check again if the database’s mtime has not changed since.

And these are just two examples, there are more possible UI improvements that would make pacman faster to use in practice, which would make a much bigger difference than speeding up database access.

By: cippaciong

cippaciong — Sun, 16 Dec 2012 17:52:35 +0000

Don’t worry, I think pacman is fast enough for most of us. =)

By: PotatoesMaster

PotatoesMaster — Sun, 16 Dec 2012 16:33:17 +0000

Hi Allan.

I put pacman database (/var/lib/pacman) on its own partition. It uses reiserFS and is 500MB large (only 50MB is occupied).
I am really pleased with pacman speed.
~ $ time pacman -Qi >/dev/null
pacman -Qi > /dev/null 0,39s user 0,09s system 76% cpu 0,624 total

P.S.: This is my first comment here.
Thanks for all you do.