[pacman-dev] undocumented features, bugs and why pacman's speed cannot be tuned...

Nagy Gabor ngaba at petra.hos.u-szeged.hu
Sun Feb 25 09:04:29 EST 2007


Pacman's speed is may tuneable!
I think that I found solutions to all of my problems:
As I wrote earlier, we should extend the local repo with additional
informations, so it would be compatible with earlier pacman versions.
To do this, there should be a "create additional information to
local repo" function in pacman, which is called automatically in the
"first" use of a tuned pacman. And in practice the additional
information is used. But if you think that the additional information
is corrupt, you may recreate it by calling this func manually.
This was a security option, but the key: we should store broken
dependencies too! (So the above "security" function can be thought of as
an integrity check too, because we store broken dependencies too, and we
may offer an option to user to fix it...).
When must we store these broken dependencies?
1. First time of course
2. Only when -d switch is used!
So my last problem disappeared:
You want to install a new package:
My problem was, that when you fill in the requiredby field, you had to
check all local packages' dependencies. But in normal case any
installed package doesn't depend on our newly installed package 'foo'
(note: -A and -U is different here!). So you have to check if there is
any broken dependencies (which is stored somehow in local/.brokendeps
for example), where 'foo' depend is missing. So you can fill in
requiredby field in 'foo'. This is fast, because in most cases very
broken deps exists (on my machine probably 0.)

Bye, Nagy Gabor

More information about the pacman-dev mailing list