KAptGet - Database questions

[loply <loply@blueyonder.co.uk>]

Evening all,

Im writing a KDE frontend for apt-get/dpkg (hybrid functionality). This will 
ofcourse, be another one of those system(); intsense jobs... Before the 
flames come in, I know apt-get and dpkg are allready easy enough to use 
without a GUI, but my motivations for development are nothing to do with 
that:-
1) Qt/kdelibs practice, Im trying to learn these
2) As a C++ excercise, Im just "upgrading" from C
3) As a design excercise in user interfaces (I think this this frontend 
offers some very interesting UI oppourtunities)
4) Because I friggin` feel like it :)

The application comes in tab pages, one for not-installed packages (with the 
option to install, download etc etc) and one for installed-packages (with 
purge, remove etc etc). There are other tab pages but they aren`t relevant.

Im going to need to display dependencies on screen when the user selects a 
non-installed package from an extremely large list of packagenames. I know 
that the dependencies arent stored in /var/lib/dpkg/available, so I will have 
to rummage through the various *_Packages files in /var/lib/apt/list, 
correct? 
Its a bit troublesome to search through multiple files to find the record.

/tmp/biglist is created via: 
cat /var/lib/apt/lists/*_Packages > /tmp/biglist; 
...when the application starts up.

At the moment, I run through the entire /var/lib/dpkg/available upon the 
application loading and display each packagename in the string list (of 
not-installed packages). When a package is selected in the list the 
application will search the file /tmp/biglist for that package; and display 
its dependencies and other info in some flashy tree views etc etc.

My questions are:

a) Is there no way I can use dpkg/apt-get to get the full information - 
including dependencies - of non-installed packages?

b) Can anybody offer any general advice on simplifying getting info about 
packages irrespective of their status, source or type, given that one 
considers having to read through database files manually to be a bad thing 
(this is a frontend, not a replacement!).

c) Any other comments?

Thanks,
Richard A. Hammond.