interpreted languages for package management

I have been thinking about package management lately. An odd thing to do, surely.

I started by pondering the current state of Archlinux's pacman utility. A fine package manager. It has some warts though, which I will not be going into just now.

>cough<

My primary rumination has been centered around the idea of package managers being written in interpreted languages. People claim that yum is painfully slow. It used to be, but it was much improved the last time I tried it. People claimed that it was slow because it was written in python, and they claimed that python is slow, because yum is slow. Wow! Circular logic with poor ol' yum at the middle of it.

• Is this true?
• Is an interpreted language an inherently bad choice for package management?
• Is Ruby Gems that slow?

I would think that the life of a package manager would be spent rolling around in one of the four following areas: User Interface, Dependency checking, Network I/O, Disk I/O.

I wouldn't think an interpreted language would add much overhead to the last two, Network I/O and Disk I/O, since that is pushed off to the underlying OS layer. That leaves dependency checking and user interface. I can't imagine the UI of a cli utility being terribly taxing, so that leaves dependency checking.

Dependency checking can be a tough business, and I would be interested to see how much effect using an interpreted language would have on this area.

Writing a package manager in an interpreted language makes some degree of sense to me. It would allow for more rapid development. It could possibly be easier to perform regression and unit tests against. It would be fun!

As to the performance considerations, a package management utility isn't used that often in regard to the overall system, so a slight performance impact would not be overly detrimental. It is not a kernel or a GUI library. Also, very slow parts could be optimized later, by writing extensions in C or using Psyco/Pyrex could alleviate some bottlenecks.