Re: dselect/dpkg
On Sat, 6 Feb 1999, Adam Di Carlo wrote:
>
> On Wed, 3 Feb 1999 17:39:18 -0800 (PST), rrr <rrr@infoquest.jeffnet.org> 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 Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
>
>
>
Roland R. Roth
rrr@infoquest.jeffnet.org
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: