I'm installing debian via ethernet to many machines in sucession as part of "Ernie's Charity Recycling". I've managed to get the install process working. This is installation on computers without CDROMs (they're scarce) via a server with a CDROM.
However, the overhead of nfs, a slow CDROM on the server machine, and the fact that the CDROM goes troppo sometimes (it does get itself sorted out eventually) means that the present way dselect operates is painfully slow (this is a charity orginisation with marginal equipment). By this, I mean going through all files in all directories of the distribution, and checking if each is marked for install. Merely listing multiple files seems a real overhead in nfs. And each time it lists a file, the CDROM might go troppo. I have an idea for how to improve the speed, which I'll go into, but I thought I'd ask if there are any options for stepping past this approach. My thought is to run a perl script which has access to a file which lists all files referenced to the binary-i386 directory (eg admin/acct_6.3.5-4.deb), and step through the file /var/lib/dpkg/status. If we find an entry "install ok not-installed" under Status, we then use the package name and search through the directory list and thereby obtain the filename. We then use the dpkg --unpack command to unpack the file. After it is complete, we do --configure --pending. There are degrees of automation - I could just have a list of files I install via a script, but the remaining functionality of dselect is appealing, and I do not want to go this far. Anyway, is this a good idea or are there other approaches ? Yeah, I'm not using the latest debian ... but dselect still operates via the "recursive directory search", right ? As a separate question - dselect notwithstanding - is there is a way of listing the "tree of dependencies" for a given package, so you have an idea of all the packages needed for a given one to run ? I'm not on the list, but am using a mail-news gateway, and should be able to read list replies. Thanks, -- John August It is, because it can be.