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.
