Re: [Rule-list] vacuum example

[Eugene Wong]

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