Re: dselect/dpkg
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"
(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 Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: