[Rule-list] vacuum example

[Martin Stricker]

Eugene Wong wrote:

> >From: Martin Stricker <shugal at gmx.de>

> >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/.

That's the location I ended up with myself, too. And it even makes sense
(not all in FHS does for me). So let's use /var/spool/vacuum/.

> 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:
> [root at ew486 root]# ls /var/spool/
> cron  locate  mail  vacuum
> [root at ew486 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".

Idea: Rename /var/run/vacuum.tmp_lst to /var/spool/vacuum/todo.list
and keep the list of things that were moved here in there. Then a
vacuum --empty would do something like
cd /var/spool/vacuum
rm -rf *
touch todo.list

> 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.

Hmmmm... that would require vacuum to check with the output of mount
before doing anything, right? Or is there another way? Maybe vacuum
should be restricted to ext2/ext3 filesystems, so no one ruins a Windows
installation? Oh well, why care... ;=D

> >...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.

Danger, Will Robinson, danger! ;-)) I have a bad feeling with this,
blindly overwriting a whole directory tree... And I want to be able to
`vacuum -r qwertz` (because that's the German keyboard ;=D ), and thus
restore my keyboard, without stating the complete path, and without
restoring all those other keyboards and other stuff that I prevacuumed
before. Yeah, I'm lazy... ;=D I think the todo.list would be convenient
for this, and to manually took up what's still to be erased.

> 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.

Sounds good - just give me the chance to erase only parts of that
directory, but restore others (which could be done earlier).

> >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.

> >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.

As said, I have the habit of finding all the weak spots in a proposal or
actual code... I then lean back and watch how the developer reacts. It's
fun! ;=D

> 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.

Afgreed absolutely. I pointed this out for two reasons: 1) make it a
*big* "known problem" in the man page of vacuum and 2) I hoped someone
would have an easy to use way of dealing with the RPM database...

> 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.

Again I agree.

> 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.

*dreamily looking*

> >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! :^)

I'm glad you see it that way! ;=D

> It might have been easier to say:
> 
> [root at ew486 run]# ls /usr/lib
> /* Pretend that locale/ is missing from /usr/lib */
> [root at ew486 run]# ls /usr/share
> /* Pretend that i18n/ is missing from /usr/share */

Ah, so you indeed wanted to say what I thought you should have said...
LOL

> 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.

`man find` should give you this. Too tired and lazy to look myself
now... ;=D

> 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.

Web links, *and* the names of man or info pages to check (I hope some do
exist!). Many people still have to pay expensive fees per minute for
internet access (I'm one of those).

Best regards,
Martin Stricker
-- 
Homepage: http://www.martin-stricker.de/
Linux Migration Project: http://www.linux-migration.org/
Red Hat Linux 7.3 for low memory: http://www.rule-project.org/
Registered Linux user #210635: http://counter.li.org/


_______________________________________________
Rule Project HOME PAGE:  http://www.rule-project.org/rule/
Original Rule Development Site http://savannah.gnu.org/projects/rule/
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list