Package: wajig
Version: 2.0.37
Severity: wishlist
Running "wajig new" takes a very long time:
$ time wajig new
[... wajig new output, 5 packages ...]
real 1m36.576s
user 1m35.570s
sys 0m0.652s
I haven't profiled it closely, but I assume there is some bad
algorithmic behavior. As a proof of concept, I created the following
shell script that does the same thing much more quickly:
-- >8 --
#!/bin/sh
OLD=$HOME/.debnew-packages
NEW=$OLD.new
set -e
update() {
test -e $OLD || touch $OLD
apt-cache pkgnames | sort >$NEW
}
show() {
echo '==> Added packages'
comm -13 $OLD $NEW |
xargs --no-run-if-empty apt-cache show |
perl -ne '/^Package: (.*)/ and $package = $1;
/^Description: (.*)/ and printf "%-24s %s\n", $package, $1;'
echo '==> Removed packages'
comm -23 $OLD $NEW
}
case "$1" in
mark) mv $NEW $OLD ;;
*) update; show | less -S ;;
esac
-- >8 --
On the same dataset (and producing the same results, albeit with
slightly different formatting):
$ time debnew
real 0m2.390s
user 0m2.048s
sys 0m0.348s
Is there any interest in trying to integrate this into wajig? It might
also be possible to simply fix the performance issue currently in wajig,
but I don't have any experience with profiling python, so I'm not even
sure which part of the code is the culprit.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-2-k7 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages wajig depends on:
ii apt 0.7.6 Advanced front-end for dpkg
ii dselect 1.14.6 user tool to manage Debian package
ii python 2.4.4-6 An interactive high-level object-o
ii python-apt 0.7.3.1 Python interface to libapt-pkg
ii python-central 0.5.15 register and build utility for Pyt
wajig recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
