On Sat, Apr 25, 1998 at 09:26:24AM +0200, erikyyy@studbox.uni-stuttgart.de wrote:
> hm. after updating some packages i found out that old directories still
> exist. (the older packages didn't clean themselves the right way)
> should there be a possibility to do something like
> dpkg --overall-consistency-check
> to check the whole system ?
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.
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.
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.
> 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?
> emacs packages could warn you that you still didn't erase the old
> directories.
> of course all files that are in the package could be checked. (e.g. did
> the user remove /bin/sh ?)
cruft *does* handle this at least.
> 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.
Reinstalls are for new computers.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
Attachment:
pgps2hRf6cSKH.pgp
Description: PGP signature