I will try to address your call for comments, though it will be a matter of several responses, and not one.
My machine is minute (though I hope to replace it fairly soon). I have been running a Debian system for well over a year. All my maintainance has been done using FTP to get the packages. My experience with the Debian system has led to the impression that the developers must all have terabytes of storage at their disposal---I do not, and I have found myself up against the ceiling consistently ,for example for the past several months. I do have a fairly substantial (in my terms) swap partition. Maybe I have missed the point, but I would really like to be able to install a package without having the package file left on the system to deal with. Would it be possible to build an option into the package tool to install from FTP without saving the package? Somewhere between an NFS mount and dftp, which has to get the files first. Another thing that would help would be to HAVE ALL FILES IN /var/lib/dpkg/info IN GZIPED FORMAT. My little system now has 893KB in that directory, and I have gziped almost all the postinst scripts by hand. I haven't mentioned the over 700,000 bytes in the Packages file. Maybe a bit excessive on a system with a 200MB hard disk. Why not gzip this too? This is beyond the scope of your request and your work, but I might mention that perhaps a year ago there was a thread on this mailing list, with vehement arguements both for and against gziped man pages. One of the arguments against it was the time it takes to unzip a file when reading a manpage. Now, I laugh at that argument---when I call for a man page, on my 486SX-33 notebook, the greater part of the time of getting the man page displayed is not in formatting it, or ungziping it, but maintainance of the database---it can 30 seconds to update the database. What was that to do? Slackware was a lot faster, using all catman pages. SURELY there is a faster man utility. Is there an alternate manpage facility that is any faster? Debian has recently evolved toware fragmentation of single packages into many has left me confused. What does it take just to know what packages are needed? Some way is needed to keep track of which packages are needed for a single package install. Maybe the package info headers are not informative enough. I don't use dselect. Perhaps things are getting better. It is really nice to be able to install a working package without hassle, and to have the configuration well organized by a good package developer---I might mention smail. I applaud the suggestion to handle the configuration scripts in a consistent way, but if this gets too complicated, it will probably add to complexity. I would also like to see more meaty documentation on some of the packages, along with some possibility of getting information about the configuration. I don't think this is so far from actuality, though, as many package developers have provided this in README.debian files, etc. Perhaps more encouragement of good practices will be enough. Debianized source code confuses me. I have not been able to make sense of debianized source. Is the putative advantage of debian's method of handling kernel headers sufficiently better to justify the ensuing confusion? (Not withstanding problems I had myself with a recent kernel and modutils/modules compiling). I use my linux system to learn, and I have been able to install many well designed packages by compiling them. But debian is going off in some direction of its own, leaving me behind. I don't want an idiotproof linux. Well, all that being said, I hope the alternative insights of one man out, the user with a small system, will be useful in some way. Alan Davis -- [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .