aptitude slow in edgy because it does not (yet) uses pkgDepCache::ActionGroup()

Confirmed. It makes aptitude mostly unusable for me...

Set status to confirmed.

I should note that this is only with aptitude's text mode gui. aptitude from the command line (aptitude update, aptitude dist-upgrade, aptitude install....) seem to work normally.

For me it hangs for a few minutes on the commandline as well.

yes since a few days it hangs also on the command line

It always rebuild the whole packages cache...

Same here.
Some more information:
I'm running Dapper plus edgy enhancements (switching in progress...), and since the latest upgrade of apt (0.6.44.2ubuntu4), aptitude (0.4.1-1.1ubuntu2) and dpkg (1.13.22ubuntu4).
Now when I invoke aptitude all those progress bar increase in parts of seconds, only the building of the package state takes up to minutes (on a AMD K7 2800+), and the cpu usage is high up in the nineties. Updating the packages list and installing/upgrading packages works fast as usual.

Pls let me know if I can be of more help to track this down.

Switching to apt_0.6.45 from debian unstable fixes this problem.

Hopefully someone takes a look at this before Knot 2 is released. Quite annoying bug..

Removing /var/lib/aptitude/pkgstates makes aptitude start fast again once, but obviously resets all packet states not saved in apt/dpkg (like manual/automatic install).

I know what the problem is and will fix it with my next upload.

Latest update has this fixed for me.
Thanks Michael.

aptitude (0.4.1-1.1ubuntu3) edgy; urgency=low

  * rebuild to enable ddtp support
  * debian/patches/09_no_crawl_in_extended_states.dpatch:
    - fix the problem that it is very slow when applying the
      extended selections

 -- Michael Vogt <email address hidden> Mon, 14 Aug 2006 17:01:56 +0200

I'm sorry, but 0.4.1-1.1ubuntu3 still does this for me.

Not fixed here.

@Mikael Nilsson:
Hm, interessting. It fixes the problem on my development and on my test-system. In what step is it hanging for you?

It hangs on "building tag database" just like it has for a number of weeks now.

This is on the command line, "aptitude upgrade", BTW.

Can I help test in some way?

Sorry, it hangs *after* building tag database, the "done" is printed quickly, but then I have to wait for two minutes before I get to see the suggested upgrades.

Thanks, this is a differnet bug then, I reopen it and retitle it.

just for the record, your fix, fixed it for me. works fine now.

"aptitude upgrade" doesn't hog cpu on my box anymore, looks like version 0.4.1-1.1ubuntu3 fixed it for me. Thanks.

ignore my earlier comment, "upgrade" bug is still present..

It is fixed for me as well.

aptitude still feels more sluggish than in dapper (for example when selecting a package for installation) but at least it's usable now.

Thanks a lot!

a related bug. In aptitude, if you "purge" a large group of packages (i.e. do a purge on "not installed" packages, for instance to remove cruft). It just hangs forever (well exageration, but it was over 20 minutes at 99% cpu usage)

If you do it on smaller sets (i.e. admin/main) it hangs for an extended period of time as well, but does return.

This bug is still present for me in aptitude 0.4.1-1.1ubuntu3.

Hopefully importance of this bug gets raised a bit. This is still present on Edgy Knot 2 and makes aptitude upgrade a pain to use.

Friedemann Schorer im not deniing this is your issue but mixing dapper and edgy is gonna give you problems that might seem the same but may not be. i advise you to re-think mixing dapper and edgy repos.

I have just upgraded to aptitude0.4.1-1.1ubuntu6 and still have the issue, where on an upgrade, it hangs for two minutes saying "building tag database".

The latest (aptitude 0.4.1-1.1ubuntu7) upload should fix most of the speed issues. I keep the bug open because there are still other bits to work on.

works much better for me, I can now do a purge on all "uninstalled" packages without it chewing up cpu.

aptitude 0.4.1-1.1ubuntu7 has solved the issue for me. Many Thanks.

Me too, fixed here.

I consider this fixed for me. If there are more performance improvements in the pipeline, all the better. But I don't see a regression from dapper anymore at the moment, so I'm already happy :)

Thanks a lot!

Thanks for confirming this. I mark it as closed for now. There is still room for improvment, but that is a different issue (better support for the libapt pkgDepCache::StateCache::Garbage flag)