[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rule-list] vacuum example
From: |
Eugene Wong |
Subject: |
Re: [Rule-list] vacuum example |
Date: |
Fri, 29 Nov 2002 23:10:46 -0800 |
I just realized that this is much like "strip". "strip" is for binaries and
unused functions, right? Well, this is for packages, & unused files &
directories. Interesting.
From: Marco Fioretti <address@hidden>
<snip>
2) If I understand it correctly, vacuum wil be optimum as a way to
re-gain disk space *after* a standard package, or set of package, has
been installed, right?
Yes, exactly!
For example, install Emacs and Ghostscript (31
and, respectively, 29 MB on RH 8.0) then eliminate fonts that will
never be used, emacs games, emacs mode for unwanted programming
languages, emacs mayan and moon calendars (yes they are there...)
right?
Exactly.
This is excellent, but please evaluate if it is possible to make this
approach compatible (using same config files and lists?) with the case
when simply there is not enough disk space to install all and trim
after: in that case, we decided some months ago, the installer should
have available one vacuum-like script for each package so that:
rpm -Uvh foo # install foo, bloat and all
vacuum foo # remove foo bloat
rpm -Uvh bar # install bar, bloat and all
vacuum bar # remove bar bloat
............
I see. I was thinking today about making this work well with Slinky &
Miniconda. The easiest way that I can think of is to have the user copy
preference & config files onto the install disk. Another option is to have
the install disk prompt for the user to insert a floppy that contains the
preference & config files.
As far as I can tell, it would be much better if I can make Vacuum unware of
install scripts & rpms. This way Vacuum would be good at 1 thing. Any other
program that wants to make use of it should call it with the appropriate
arguements.
Comments? Suggestions?
3) rpm can install packages without documentation (--nodocs option or
something like that): if used like above, the vacuum scripts must not
crash if run after rpm --nodocs, ie when their targets are not there
Yes, I would like Vacuum to make use of "rm -rf myfiles", to get rid of the
files. If I could have it my way, it would run through the full list every
time, not just the temp list, just in case a package installed some files
again without letting the user know.
4) another way to save space is remove uninstalled languages:
on an english only system I still get:
<snip>
Many, many packages do this...
Yes, agreed. I'll be sure that languages are the 1st few things that get
removed. Perhaps, Vacuum could look in /etc for the keyboard layout choice &
language choice, and remove all else. Perhaps it could be called "vacuum
--suggestions".
Comments? Suggestions?
5) one way to avoid using --nodeps when removing whole packages is to
generate the correct order with DAn (patching it,
www.rule-project.org/en/sw/dan.php) or similar tools
<snip>
Yes, agreed. I was thinking of making some more scripts for better package
management. What I have in mind is a script that would uninstall the
requested package, but before that, it would check for dependencies. If it
depends on packages that will no longer be depended on, then it should
suggest to the user that these packages can be removed.
I find that rpm has the habit of installing things, but never removing
things. This script could help to deal with that.
I'll look into DAn.
From: Martin Stricker <address@hidden>
Eugene Wong wrote:
<snip>
Definitely. Not yet sure where exactly under /var, I'd have to look at
the FHS http://www.pathname.org/fhs/ and where Red Hat puts their stuff.
I decided to check, to see if I could understand it better now. I think that
I do. I'll wait till you reply, till we come up with anything "official",
but in the mean time, I'll use /var/spool/vacuum/.
*blush* ;=D So I drop some more ideas below...
Good!
> address@hidden i386]# vacuum azerty
> address@hidden i386]# ls
> azerty dvorak fgGIod include qwerty qwertz
> /* Notice that the files are still there. They will be deleted when
> we run "vacuum --empty" or whatever the script is called. */
So vacuum does just keep a list (/var/run/vacuum.tmp_lst) of things to
delete? I would prefer if it could move the files to some kind of
dustbin, so I can *test* what happenes when I delete the stuff before
actually deleting it.
Yes, it does keep a temp list--at least that it what I was suggesting. I
agree with what you say about being able to test it. Therefore, I'll try to
make Vacuum move the file and its directory names to /var/spool/
For example:
address@hidden root]# ls /var/spool/
cron locate mail vacuum
address@hidden root]# ls /var/spool/vacuum/
usr/
lib/
usr/
To see the files & directories for deletion, the user has to enter into
these directories, or list the subdirectories. Perhaps the easiest way is to
use "locate spool/vacuum".
After that, the user can eliminate at his convenience. An interesting thing
that may need to be considered is making the directory secure so that _only_
files & directories from the local system can be sent there.
> address@hidden run]# vacuum --empty; cat vacuum.tmp_lst
> address@hidden run]# cat /var/db/vacuum.db
> /usr/share/i18n/
> /lib/kbd/keymaps/i386/azerty/
> /lib/kbd/keymaps/i386/fgGIod/
> /lib/kbd/keymaps/i386/qwertz/
> /usr/lib/locale/
<snip: explanation of the above example>
...So vacuum -e (like rpm -e) or --empty (it would be nice to
have both long and short options) deletes the files which have been
prevacuumed (hopefully to an interim directory like /var/spool/vacuum)
by processing /var/run/vacuum.tmp_lst. There should also be vacuum -r or
--restore to revert the prevacuuming.
Yes, except now that we have /var/spool/vacuum/ we don't need
/var/run/vacuum.tmp_lst anymore, unless you feel otherwise?
To send the files to /var/spool/vacuum/ and restore them, I would like to
have the script just make use of mv. It seems so much easier to have the
script do "mv usr/lib/locale /" in order to restore the directories & files.
To permanently delete the files, the script could just "echo
usr/lib/locale>>[permanent config file]", then do "rm -rf
/var/spool/vacuum/usr/lib/locale/". Any other files & directories in
/var/spool/vacuum/usr/lib should remain.
Comments? Suggestions?
And I have another idea/concern: Since Red Hat Linux and other distros
are based on RPM, the RPM database stores information about each file
installed by a RPM package. Wild vacuuming would make this database
inconsistent with reality. I don't know if it's possible to tell the RPM
database that some files have been deleted, but I think I would get
errors if I tried to rpm -e a package from which I vacuumed some files.
But that still doesn't prevent that dependency checks might go bad
because the package to be installed depends on a vacuumed file that it
believes to be still there... Oh well, so vacuum is for experienced
users...
Oh dear, oh dear. I never thought about that. I guess that my response is to
blame the programmers for not giving better error messages. If there is an
library or file missing, then the software should give a detailed suggestion
on how to fix the error, & to not force the user to install only certain
packages. This is complex. I never intended Vacuum to be a be-all & end-all.
It was only supposed to help with the obvious files & directories, for
simple installations, for users who only want to do a few things [such as
surfing the Internet & checking email]. As long as Vacuum gives us a little
more than what we can get now, then it would be worth while. The more I
think about it, dependency issues should really be a rpm problem. Vacuum
just helps us to gather up many files & delete them, in the same manner that
strip uninstalls things. Also, Slinky KickStart files & Miniconda KickStart
files, should contain the same rpm lists as when it was last installed or
last configured. I would like Vacuum to stay well away from configuring
Slinky, Miniconda or KickStart files.
I'm hoping that as the project gains momentum, experts will come along &
take over the project. Also, I'm hoping that rpm will mature a little &
become a little more user friendly.
Don't be worried too much, I have the habit to point to all the possible
problems early, so they are considered while developing... ;-)
...& that is the way that we should do it! :^)
> address@hidden run]# ls /usr/lib
> /* Pretend that locale/ is missing from /usr/lib */
> address@hidden run]# ls /usr/share
> awk emacs magic man openldap ssl vim
> dict empty info magic.mgc misc pixmaps tabset zoneinfo
> doc groff locale magic.mime nmap printconf terminfo
> /* i18n/ is missing for the purposes of this illustration. In the
> real situation this directory would list properly. I just deleted
> the text for the sake of this sample, & didn't want to rearrange
> everything. */
Sorry, but I do not understand this. Could you please explain why you
removed the directory for illustration, but when using the *real* script
it should be there? Hrm, this sentence doesn't make much sense either -
time to go to bed! ;=D
Well, it was late, & I wanted to say this:
address@hidden run]# ls /usr/lib
/* Pretend that locale/ is missing from /usr/lib */
address@hidden run]# ls /usr/share
awk emacs info magic.mgc misc pixmaps tabset zoneinfo
dict empty locale magic.mime nmap printconf terminfo
doc groff magic man openldap ssl vim
/* i18n/ is missing. */
When I look back at what I said the previous night, I find it humourous that
that which made so much sense at that time, conveys the exact opposite of
what I intended. :^) It might have been easier to say:
address@hidden run]# ls /usr/lib
/* Pretend that locale/ is missing from /usr/lib */
address@hidden run]# ls /usr/share
/* Pretend that i18n/ is missing from /usr/share */
On an unrelated note, it might be good to add a feature that searches
through the entire filesystem structure to see when files were last
accessed. Is that even possible? If so, then the user should be able to make
an informed choice about what to vacuum.
Also, in the man pages, we should give some web links on l10n & i18n, &
other info to give the user an idea of what to do.
Sincerely, and with thanks,
Eugene T.S. Wong
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail