On Sat, 6 Feb 1999, Adam Di Carlo wrote: > > 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"
I hosed it by the following procedure: I couldn't run 'make menuconfig' because of crossed ncurses installs so I (stupidly) killed ALL ncurses via dselect. Wasn't able to do ANYTHING to repair system without ncurses so I used a set of old install images and installed the base over my existing system to get ncurses back in. > (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. Tried this FIRST, but wasn't to able to get the status to reflect the installed software base. It's a moot point as I have everything put back together (well after I check the installed software against what dselect/apt thinks is there - but it seems pretty close at this point). > Repairing that stuff is a question of using backup files or your > backup routine -- you do backup your system, don't you? Only my work and /etc - will add /{usr,var}/lib to that. ;) > > As for not having to redownload, that's what caching proxies are for. I have a lightwieght cacheing proxy setup - I will look into squid or something. > > I really don't see any opening for some system recovery script > here.... Nor I now - I'm in over my head there. The fact is, is that I did some really stupid stuff, because I was in a hurry. I appreciate all the input and you all putting up with me here. Again, thanks very much for all your time. > > -- > .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/> > > > Roland R. Roth [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
