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.

Reply via email to