On Sat, Apr 25, 1998 at 06:11:25PM +1000, Anthony Towns wrote: > If you're running a hamm (Debian 2.0, frozen) you might like to look at > cruft (cruft_0.9.4_i386.deb, still sitting in Incoming; try > ftp1.us.debian.org:/pub/debian/Incoming > or your favourite Incoming mirror) which does something like this.
Just snagged it.
> In particular, it checks that all the files listed as alternatives, as
> diversions and in the dpkg database itself are all present and accounted
> for, and produces a list of things that weren't listed but are still on
> your system, and things that were listed, but aren't. It also takes into
> account symlinks (if you've got a symlink from /usr/tmp to /var/tmp, it'll
> complain if /var/tmp doesn't exist, for example), user home directories
> (it'll make sure that everything in /home/aj is owned by aj, for example),
> and a couple of other things.
VERY interesting results. I highly suggest throwing the output to a pager
if you do anything at all with it. It did complain about every single file
it didn't know was going to be there. /usr/src/* for example (about 4
kernels worth of files); everything on my fat partition (which will be gone
as soon as I discover the best use of the space currently taken up by it)
was also displayed.
It noted all the things left over from local installs (or attempts at same)
and that'll help me clean things up a bit---this is good.
Pointed out a policy issue too.. xfstt in slink (I run hamm, but snagged
that package greedily when I heard about it) puts fonts in /var/ttfonts.
Would those not be better found in /var/lib/xfstt/fonts with a symlink just
in case?
It pointed out some problems I don't know how to fix properly, though:
---- missing: alternatives ----
/etc/alternatives/editor.1
---- missing: diversions ----
/usr/bin/addr.bind
/usr/bin/dig.bind
/usr/lib/nslookup.help.bind
/usr/man/man1/addr.1.gz.bind
/usr/man/man1/dig.1.gz.bind
/usr/man/man8/nslookup.8.gz.bind
---- missing: dpkg ----
/etc/im/im_palette.pal
/sbin/ldconfig.new
/usr/bin/perl.dist
---- missing: alternatives ----
/usr/X11R6/bin/rclock
/usr/X11R6/bin/rxvt
/usr/man/man1/nvi.1.gz
---- missing: link_dests ----
:
---- unexplained: / ----
:
The dangling links others have commented about. There are missing files
which are my fault. All in all, there's still a few problems with hamm I
think.
> It's still a work in progress -- in particular there are bunches of files
> that are created when packages are installed but dpkg is never told about
> (/etc/passwd is one example), which cruft doesn't cope with too well at the
> moment -- but it's a start, at least.
Hey, don't be too hard on yourself, it's helped me recover massive diskspace
and maybe the above will help fix some problems with my system and with hamm
in general.
> > e.g. every package that has a checkscript gets this checkscript executed.
> > this way some kernel packages could check, that the user doesn't install
> > the wrong include files by hand, because he thinks, debian
> > is wrong, and he is right instead (asm,scsi,linux, you know the
> > problem...)
>
> This is an interesting idea; one that cruft doesn't even attempt to
> address.
>
> In this particular case there are a few things. First, if the user *does*
> do this, dpkg will warn them anyway (and I'd presume this would show up
> under dpkg --audit). The only advantage in doing it this way is that the
> libc6-checkscript could provide some explanation as to why this is a
> problem, which dpkg probably couldn't.
>
> I'm not entirely sure this is an appropriate sort of thing to nag the
> user about; we've already got the FSSTND which tells people not to touch
> stuff that we put there, and I'm of the opinion that if the sysadmin
> chooses to violate this then that's their choice, and I'm somewhat
> disinclined to nag them about it.
>
> I could certainly include something like this in cruft (after doing all
> it does currently, it could happily just call all the scripts in
> /usr/lib/cruft/checkscript/ or somewhere similar) and present any results,
> but I'm not entirely convinced that this would be a particularly useful
> thing to do. Are there other examples of things where a script would be
> useful to check that an install hasn't gone weird?
I think you should institute support for checkscripts and I think it should
be suggested everyone use them in their packages. If packages were better
equipped to clean up after themselves... It's possible that if you ran the
checkscripts FIRST they would actually be able to clean up the small things
and then cruft could see what in addition it thought needed fixing.
Yathink?
> > i am always not sure, wether my system is OK. :) sometimes it might be
> > useful to do a new installation (no update) only because then much of the
> > old unneeded rubbish is gone.
>
> *shudder*
>
> Reboots are for new kernels.
and for power outages and shutdowns for lightning storms till I get better
hardware... =p
> Reinstalls are for new computers.
I may still reinstall mine. There's a number of real screwups I made in
partitioning, but it'll be a nightmare backing up and a week with apt
reinstalling afterward. I think I would put a standard MBR on the thing and
put lilo on hda1, call it good. Put / on a small disk instead of the 800
meg partition it's on now and mut /usr and /var on seperate partitions like
/home is. That sort of thing.
It's either get a new HD or backup/reinstall. ugh.
pgp8vdLlwd4sf.pgp
Description: PGP signature
