Yes, aptitude can list packages by priority, but what I wanted was a simple list of just package names. I've got two ways of getting a bare list:
Updated with many thanks to
Phil Hands.
$ aptitude search '~prequired' sed -ne 's/^i [ A] \([^ ]*\).*$/\1/p' tr '\n' ' ' sort -u fold -s ; echo
#!/bin/sh
# Licence: GPL-3+
FILE= find /var/lib/apt/lists/ -name '*unstable*Packages'
LIST= grep-dctrl -n -s Priority '' $FILE sort -u
for P in $LIST; do
[ "optional" != "$P" -a "extra" != "$P" ] continue
echo "Priority: $P"
grep-dctrl -n -s Package,Priority "$P" $FILE sed -ne '/^'$P'$/!h;/^'$P'$/ g;p ' tr '\n' ' ' fold -s
echo
done
The advantage with the script is that is lists all packages in all priorities except optional and extra and can be restricted to individual Packages files and therefore to individual repositories and components. (Change the find expression if you have more than one repository specifying unstable or adapt the script to accept a path to the relevant Packages file on the command line.)
I really ought to have used perl because pattern matching in perl is a
lot more natural to me than using sed or awk. I do tend to chain a
couple of sed commands, just so that it's easier to work out which bit
is broken when it breaks.
The final version of this script will end up in emdebian-grip-server,
converted to perl with POD content, translated and reading the Packages
files using Debian::Packages::Compare.
$ ~/scripts/list-priority
Priority: important
adduser apt-utils apt aptitude bsdmainutils libbz2-1.0 cpio cron libcwidget3
debian-archive-keyring dhcp3-client dhcp3-common dmidecode ed libgdbm3 gnupg
gpgv groff-base ifupdown iproute iptables iputils-ping logrotate libept0
libsigc++-2.0-0c2a libtasn1-3 libusb-0.1-4 man-db manpages module-init-tools
nano libncursesw5 net-tools netbase netcat-traditional libnewt0.52 whiptail
libssl0.9.8 libpopt0 libreadline5 libreadline6 readline-common rsyslog
tasksel-data tasksel libwrap0 info install-info traceroute udev vim-common
vim-tiny wget libxapian15
Priority: required
libacl1 libattr1 base-files base-passwd bash coreutils debconf-i18n debconf
debianutils diffutils dpkg e2fslibs e2fsprogs libcomerr2 libss2 libc-bin libc6
findutils gcc-4.3-base gcc-4.4-base libgcc1 libstdc++6 grep gzip hostname
lsb-base libdevmapper1.02.1 lzma liblocale-gettext-perl libselinux1 libsepol1
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libunwind7 mawk
libncurses5 ncurses-base ncurses-bin libpam-modules libpam-runtime libpam0g
perl-base procps sed sensible-utils login passwd libslang2 initscripts sysv-rc
sysvinit-utils sysvinit tar tzdata bsdutils libblkid1 libuuid1 mount util-linux
zlib1g
Priority: standard
apt-listchanges at bash-completion bc dc bind9-host dnsutils libbind9-50
libdns53 libisc50 liblwres50 bsd-mailx libsasl2-2 libdb4.8 libdb4.5 libdb4.6
libdb4.7 debian-faq doc-debian doc-linux-text libc6-i386 locales exim4-base
exim4-config exim4-daemon-light exim4 file libmagic1 gettext-base libgnutls26
libgpm2 libkeyutils1 libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt6
libkadm5srv6 libkdb5-4 libkrb5-3 libkrb5support0 less lsof libcap2 libedit2
libevent-1.4-2 libgc1c2 libgcrypt11 libgpg-error0 libgssglue1 libidn11
liblockfile1 libnfsidmap2 librpcsecgss3 libunwind7-dev libxml2 m4 mime-support
mlocate mutt ncurses-term ftp telnet nfs-common libldap-2.4-2 openssh-client
patch libpci3 pciutils libpcre3 perl-modules perl portmap procmail
python-central python-minimal python python2.5-minimal python2.5
python-reportbug reportbug wamerican libsqlite3-0 tcpd texinfo time ucf w3m
whois
Hmm, next step is to check the "Priority: standard" set for Emdebian - it looks far too large for what would be standard on an embedded device. LDAP will be dropped for one - and what is a -dev package doing in there? libunwind7-dev isn't even installed on my amd64 Debian desktop!
Probably check the important and required listings too, then tweak what we need to change via the
archive overrides for Emdebian Grip.
Come to think of it, I might need a PHP version of this to read live data from the repository, documenting the changes.
A new littler
release (now at 0.1.3) just went out of the door this evening.
littler provides 
Debian's package manager dpkg has the perhaps unique feature that it distinguishes between removing and purging a package. Removing it removes the program files but keeps the configuration files (and sometimes the logs) around, purging it really removes everything. While this distinction undoubtedly has some uses, I have found that I almost never make use of it. I think in about six years of using Debian I have actually needed a remove-but-not-purge functionality about five times, during some really tricky upgrades (and using Aptitude instead of APT might have helped, not sure) and once when I wanted to build a package that had a build dependency that conflicted with a package I had installed (cowbuilder came later).
After 
This has been a big decade for me.
Ten years ago, I was living in Sunnyvale, in the heart of
Silicon Valley; VA had just had its 
On the train to my parents' house for Christmas I finished up a wild run
through the book 
The book is a collection of interviews with 15 great programmers of our time,
starting with Jamie Zawinsky and ending with Donald Knuth. It's written in an
interview style each interview starts with a brief introduction to the
person being interviewed, summarizing what the person is known for and what he
or she has accomplished and a few of the highlights of the interview, and then
a transcript of the interview follows, with the author/editor, Peter Siebel,
will saying something or asking a question, and the interviewee responding. I
was skeptical about this format at first because I feel like it can be an easy
way out of good editing and make the reader have to do the work of the editor,
but on finishing I think that Siebel uses the format to his advantage in this
case.
For one, the speech format allows the reader to really form a picture of how
the person being interviewed speaks and would act in a conversation. Jamie is
somewhat bitter and pretty informal. Brad Fitzpatrick is flippant and
energetic, his speech littered with profanity and colloquialisms. Others seem
more stately and verbose Joe Armstrong's responses can go on for a page or
more. In this way, not only do readers learn something about what these greats
have learned about programming, but we also feel a bit more like we've met or
know them, and can connect to them more as people.
I always have this problem where I want to read computer books, but often
computer books seem inextricably tied to the computer, so there's this dynamic
of reading a bit and then wanting to get on a machine and try something out,
write some code, play around especially with books focused on a specific
language. Coders at Work retains some of this computer-book dynamic in that I
constantly encountered things that I want to investigate or play around with
more: Erlang, OCaml, various papers and essays, Knuth's literate programs, and
books such as Higher Order Perl and others. Siebel makes a point to ask each
person what her short-list of books and papers programmers should read are, so
this book is a great source of pointers to other reading material. Unlike a
more specific book, however, keeping a list in a notebook was enough to settle
the mind to read away-from-a-computer for chapters at a time.
It's obvious that despite the interview format, Siebel has done some serious
editing. None of the prose is boring to read, and I can't imagine that the text
is a straight transcript of how the interviews went. He also has arranged the
interviews in an order such that different interviews play off each other. In
Branden Eich's interview, for example, he disparages the book
Design Patterns:
It seems strange to me. I don't think I know people as aware of internationalization issues as