DEITY TEAM -- Response to call for comments
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
--
adavis@saipan.com
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: