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

Dan McGee dpmcgee at gmail.com
Sat Feb 24 18:40:16 EST 2007

On 2/24/07, Nagy Gabor <ngaba at petra.hos.u-szeged.hu> wrote:
> Hi!
> I looked into the source of pacman (I want to speed it up), I haven't
> finished yet, but I'd like to share some of my impressions:
> 1. There are some undocumented features: -Syy (force sync remote repos),
> -A, -U can install from http://, ftp://; -Sgg list groups with their
> content

I added these options to the pacman manpage.

> 2. The main problem with speed, that pacman always reads the repos: I
> thought, that in the case of sync repos, this is absolutely not needed
> in most cases (an "ls" is enough) and when all information is needed
> (e.g. when -Ss is invoked) we may use the ungziped db.
> But of course, in local repo we cannot use a db file. I am
> disappointed, because in almost all cases (-S -A -U) the whole localdb
> must be cached.
> Why?
> Because of conflict checking and provide checking (this problem can be
> solved, as I wrote in my previous e-mail; but needs to convert
> (just adding some new symlinks to) the existing local repo). The main
> problem, when you install a new package, it is needed to fill in the
> requiredby field (you may say, that this is needless, nut it's not,
> because you may have broked dependencies with -d earlier) :-(
> 3. Probably when 2 packages provide the same content and they are not
> mutual, bugs can happen: as I can see from the source (someone should
> test) if foo1 and foo2 provides foo, and you install foo3 which needs
> foo, then requieredby foo3 is set for both foo1 and foo2. And you won't
> be able to remove neigther foo1 and nor foo2 until you remove foo3,
> however foo3's foo dependency is satisfied until at least one of the
> foo-providers is installed.

I think it is good to attempt to speed pacman up, but at the same
time, how much of an issue is it once your db is loaded into cache? I
have very few complaints about speed besides the time of that first
run, and even that isn't that bad. I do run pacman-optimize as a cron
job once a week, which may be a helpful suggestion for a lot of

I guess it comes down to this- I don't want speedups to be a hack and
have it fail on me- I think stability of your database is more
important than speed.

I've never broken dependencies with -d, so I really enjoy being able
to look at the required-by field and have it tell me the right things.
Getting rid of this would be a mistake.


More information about the pacman-dev mailing list