On Wed, 3 Feb 1999 17:39:18 -0800 (PST), rrr <[EMAIL PROTECTED]> said: > On 5 Feb 1999, Adam Di Carlo wrote: >> If you are trying to correct a status file, i.e., it thinks this or >> that package are not installed but they really are, there's no good >> way to do that that I can think of, and even some reasons never to >> do that.
> Unfortunately, this is what I want to do. i.e. dselect/apt doesn't > know that (huge download stuff like xbase, gimp, etc) is installed. > I thought about modifying package-state by hand, but decided against > that. I thought there would be some script out there that could > parse some kinda list of what each package actually installs - and > validate with a criteria of "is EVERY file this package installs, > installed?" - if so change package-state to "installed (or > not-installed)". > I only run debian as a personal system, so this isn't that critical, > but it is the reason I switched from Slack i.e. a reliable way of > keeping track of dependancies and installed software base. Well, first off lets be clear. In almost all cases, the destruction of information in /var/lib/dpkg is caused by operator error in conjunction with feature-poor dselect acquisition methods, which are now basically obsolete, such as 'nfs', 'cdrom', 'mount', 'mountable', 'ftp', 'harddisk'. For the "official" (well, not really) worldview on what methods to use for what situations, see <URL:http://www.debian.org/~aph/boot-floppies/i386/dselect-beginner.html/>. I've run Debian for 3 years now, and I've never lost any data from /var/lib/dpkg, nor have I ever hand edited the status file. Assuming you use a good acquisition method, it's basically impossible to mess up that file, barring catostropic disk failure. Secondly, you assume that /var/lib/dpkg/status is damaged. Actually, the only way to (badly) reconstruct package status is to check if the files listed in /var/lib/dpkg/info/*.list are actually installed (isn't there a way to check md5sums too?). How can you assume those files are not damaged also? What I would do as a first course is look at the backup status files in that same dir as the original status file and see if you can't backup. Repairing that stuff is a question of using backup files or your backup routine -- you do backup your system, don't you? As for not having to redownload, that's what caching proxies are for. I really don't see any opening for some system recovery script here.... -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
