Aptitude string for downgradable packages

Hello,
I'm lately doing some tests with Debian experimental packages thus I often upgrade some packages to experimental and downgrade them back to unstable.
WARNING: Downgrading in Debian is not supported etc.

aptitude search "?narrow(?installed,?archive(experimental))" -F %p|\
sed 's,\([^ ]*\),\1/unstable,'|xargs echo

This will give you a list of experimental packages installed on your system each concatenated with "/unstable". The output can go straight to "aptitude install". I don't directly use "xargs aptitude install" because it's not interactive.

Tdpkg troubleshooting and some news

Hello,
lately I've received some feedback, thanks for this.

1) Is it compatible with apt? Can I use dpkg back again after using tdpkg?
The answer is... yes! You can use what you want in the order you want, and use tdpkg when you want. Take in consideration that after using dpkg (or apt) without tdpkg, then you use tdpkg the cache will be rebuilt for consistency.

2) It's not working here (Ubuntu, other distro...), doesn't create the cache.
First of all you have to be root when first running tdpkg in order to create the cache. If this didn't solve the problem you are maybe using an untested platform. Debian uses eglibc and tdpkg has been tested on i386 and amd64. Since tdpkg does wrapping around glibc calls it might happen to not wrap the right functions. If you want tdpkg to be ported to your platform please comment here with the result of these commands:
objdump -T /usr/bin/dpkg|grep open
objdump -T /usr/bin/dpkg|grep stat
objdump -T libtdpkg.so|grep open
objdump -T libtdpkg.so|grep stat

3) Should I put the alias also for apt-get and aptitude?
Yes you have to. Aptitude and apt-get bypass the shell so the only alias for dpkg won't work.

Another thing I'd like to say is that dpkg/experimental has a patch that speeds up a lot database reading by asking the kernel to cache .list files... i.e. dpkg will avoid cold start. This brings timing from 14 seconds to about 3 seconds! At all, using tokyocabinet you get 1 second. Think that including a cache inside dpkg would mean even less than 1 second.

Have fun... :)

Tdpkg 1.0 - speed up reading dpkg database

Hello,
you may have noticed that dpkg takes a long time reading the database the first time you run it (e.g. through apt). This is because of the huge number of /var/lib/dpkg/info/*.list files (1700+ on my desktop machines). It can take up to 14 seconds and more at cold start to install/remove a single package.
Since 2007 in dpkg mailing list a first proposal (by Sean Finney) to using sqlite as cache has been posted, then a couple of weeks ago I reproposed it. No reply since then from the maintainers.

My first idea was to fork dpkg and only change the part about reading the list files. This means you had to install another dpkg version, and I haven't done it for two main reasons: most of people wouldn't have replaced dpkg and it'd have been too hard to maintain it.
The solution is tdpkg, a shared library that wrappes around glibc function calls of dpkg. You'll find in README to backup your /var/lib/dpkg/info but tdpkg is robust enough to not fuck it up.

Tdpkg comes with tokyocabinet (faster) and sqlite (handles concurrency better) cache backends. I've managed to bring cold startup time from about 14 seconds down to about 2 seconds. I will definitely have fun installing and removing applications back again.

Aptitude-gtk progress

Hello,
I was curious to see if aptitude-gtk was making some progress. I haven't followed the project since it's been merged into aptitude.
Well, I found it more functional and complete. Here's a screenshot showing pending packages for upgrade after an update:

From GNOME

The team is definitely doing a good job. Hopefully I'll find the time to give some help as I'm really interested in such full-featured GUI frontend.
Keep going on!