Now that potato has been released, I think it's time this bug has been
addressed.  Please do not downgrade its severity too hastily.

* dpkg still does not maintain an indexed, binary cache of its huge text     *
* database, and therefore requires an enormous amount of memory to complete  *
* even the smallest install.  That memory tends to end up being swap space,  *
* making every dpkg operation incredibly slow and resource-consuming.        *

This bug has been a problem ever since slink was released, and is, in my
opinion, the only major advantage RPM-based distributions have over dpkg-based
ones.  I think it is truely amazing that the largest Linux distribution is so
unbelievably weak at maintaining a large number of installed and available
packages.  I therefore believe it is in our best interests that we, the
members of the Debian project, address this problem sometime before the next
stable release, hence the release-critical severity designation.

Let's get off our rears and get the show on the road.

How does this bug

          makes unrelated software on the system (or the whole system)
          break, or causes serious data loss, or introduces a security
          hole on systems where you install the package.

?

(/usr/doc/debian/bug-maint-info.txt)

Please first explain the (IMHO way too high) severity.

This sounds to me like a wishlist bug.  Certainly no more severe than
"important".

It makes it nearly impossible (and definitely impractical) to install a
desktop Debian system (with >1000 packages) on a system with less than 32MB
(or even 64MB) RAM, which is unacceptable.  This is the fault of dpkg, and it
causes one to be unable (or nearly so) to use many other programs.

What it really is is right in between "critical" and "grave", because it
actually makes 'unrelated software on the system unusable or mostly so'.

It's not that bad - performance on 16M machines isn't going to set the
world on fire, but it's adequate, at least for me.  There's lots of room
for improvement, of course.

That tends to mean that it will automatically take out any system you
use it on.

I agree. Even on my relatively modern system dpkg is very SLOW. It has
forced me to upgrade my system so that dpkg is not such a burden. This
is my biggest complaint about Debian. I think it is far more urgent
than almost any other bug and thus deserves its high severity.

Hi,

I just stumbled across this bug, because I wondered why dpkg
is always spending a lot of time when installing new packages.
Now I wonder if the dpkg maintainers do have interest to
optimize dpkg in this aspect. Waiting for 30-60 seconds (which is
true for people with slow harddisks and/or crypto) for dpkg
to read in a lot of text files on every installation is really
a bad thing. Are there any plans to include a binary cache of the
database or something?

Best Regards,
Patrick

Patrick,

I have been annoyed by this "feature" for years but actually never
checked whether there's a report on that. I'm subscribing to this
because
I would like to see a database-supported dpkg as well. I wonder why
that still hasn't been put into practice after 9 years since this bug
was reported. And yes, the arguments from the original poster still
apply today despite the much faster machines we run Debian on. I
played around with RPM-based distributions and since RPM uses a
DB-system (Berkely i.e.), it outperforms dpkg in this regard even
though APT itself could keep up easily.

As for now, you can workaround this definancy by putting your
root-partition (including /var where dpkg's database resides) on a
solid-state disk (SSD). This speeds up the loopkup dramatically and
makes installing packages real fun.

Still, dpkg should be heavily improved in this regard. Maybe it is the
turn of the Ubuntu-developers as they have the manpower to make a leap
forward here.

Let's hope for the best,

Adrian

Here's a solution:

http://ubuntuforums.org/showthread.php?t=1004376

I think dir_index feature of ext3+ filesystems is set by default these
days, and this solves this specific problem (random access of files in a
huge directory).

There's a new project called tdpkg which can be used together with dpkg.

The tdpkg shared library is used to speed up dpkg .list files loading
using either tokyocabinet or sqlite3.

http://lethalman.hostei.com/tdpkg.html

There's a new project called tdpkg which can be used together with dpkg.

The tdpkg shared library is used to speed up dpkg .list files loading
using either tokyocabinet or sqlite3.

http://lethalman.hostei.com/tdpkg.html