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... :)
Tuesday, March 16, 2010
Monday, March 15, 2010
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.
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.
Sunday, March 14, 2010
Vala and Graphviz
Hello,
it's often useful for Vala hackers to have a graphical representation of the code tree and control flow blocks. Therefore I've created a simple application called Valag which generates four types of diagrams using Graphviz for each state of the Vala compiler.
This is the first release, there're many things to fix and enhance (like command line options) but it is working quite good already to give support when hacking Vala.
Homepage, screenshots and download here.
it's often useful for Vala hackers to have a graphical representation of the code tree and control flow blocks. Therefore I've created a simple application called Valag which generates four types of diagrams using Graphviz for each state of the Vala compiler.
This is the first release, there're many things to fix and enhance (like command line options) but it is working quite good already to give support when hacking Vala.
Homepage, screenshots and download here.
Friday, March 05, 2010
Google search wrong again
Hello,
sometimes ago I posted twice about google search having wrong results.
Now it happens again after a few months (it's like google breaks page weights like every 4-5 months).
The search is "debian dpkg list", I really expect the mailing list info page but after 3-4 pages of google search (and also bing this time) I couldn't find it. With yahoo search it's at the first position (lists.debian.org/debian-dpkg).
Like for the previous posts, using different search engines matters and matches your needs.
sometimes ago I posted twice about google search having wrong results.
Now it happens again after a few months (it's like google breaks page weights like every 4-5 months).
The search is "debian dpkg list", I really expect the mailing list info page but after 3-4 pages of google search (and also bing this time) I couldn't find it. With yahoo search it's at the first position (lists.debian.org/debian-dpkg).
Like for the previous posts, using different search engines matters and matches your needs.
Wednesday, March 03, 2010
Debian/GNOME bug triage ended
Hello,
I'm writing about the work done in the bug triage weekend of the Debian/GNOME team, started at 27th Feb and ended in 28th Feb.
The result is great, 167 bugs have been closed and many more have been triaged and forwarded upstream.
Thanks to everybody who contributed, especially to whom has done it for the first time (well, you can still continue working on the remaining bugs ;) ).
I'm writing about the work done in the bug triage weekend of the Debian/GNOME team, started at 27th Feb and ended in 28th Feb.
The result is great, 167 bugs have been closed and many more have been triaged and forwarded upstream.
Thanks to everybody who contributed, especially to whom has done it for the first time (well, you can still continue working on the remaining bugs ;) ).
Subscribe to:
Posts (Atom)