Re: Deleting uncompressed Info/Doc files at upgrades
On Tue, 20 Oct 1998, Stephen J. Carpenter wrote:
> What I consider more important is this...
> I think /usr/doc does need some special handling. Specifically...
> in the case that I don't want a /usr/doc (ie this is a machine that I am
> never going to need documentation on...and small filesystem size is the
> major imperitive)
While I can agree with what you say here, this doesn't address the issue
as I understand what is being asked for. I should also point out that,
although there are plenty of examples and yes, real documentation, in
/usr/doc, most documentation is in /usr/man and /usr/info (which are also
gzipped). Most of what is in /usr/doc/ is copyrights and changelogs.
The real question that seems to be asked by this thread comes from the
desire of the sysadmin to have control over whether or not the files in
these places (/usr/doc/ /usr/man/ /usr/info) are compressed or not.
There are good arguments for either position. Small disk space systems are
desperate to have as much compressed as possible. Systems without this
constraint tend to host large volumes of users, with lots of traffic to
and from the disk. These systems are better served by having these files
uncompressed, so other resources (like cpu time, disk activity, etc...)
can be freed up to deal with the needs of these multible users.
Debian policy is to compress these files. Debian always looks for the
greatest good for the greatest number of users, and disk space is still a
least common denominator for such decissions.
However, we should also listen to system administrators, as they have more
to do with the use of our product in "real world" situations than the
single user with an old, small, machine.
I tend to agree that dpkg is not the right place to deal with this
problem. It is really a system configuration problem, and as such needs a
system configuration tool to deal with it.
Isn't there some kind of an admin-tools package? (I don't see one in the
Packages list) A simple tool could be built to zip and unzip the contents
of selected directories, providing the administrator with tools for
managing this issue locally.
I know it isn't pretty, and I think that it would be valuable if dpkg
could at least "clean up" the excess files, but that is not necessary to
the task.
I have been thinking about the system configuration problem in general,
and I think that our failure to come to closure on this issue is because
we keep trying to design a monolithic program to "manage the system". If
we instead, follow the Unix design philosophy, and build a set of simple
targeted tools, each taking on one aspect of system configuration. In this
way, lots of "little" solutions can be created. A simple menu system (like
we already have for programs) could be made comfigurable, so the system
administrator could configure it to access the tools they find useful for
their system. As additional configuration issues come to light, new tools
can be crafted for handling them, and integrated into the existing group.
Does this make any sense?
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: