Re: dpkg problem
On Tue, Jul 10, 2001 at 10:02:03AM -0700, David Fuchs wrote:
> Joost Kooij wrote:
> >Don't use dpkg for this directly, use dselect, the proper frontend.
>
> Alright, sir, I believe we're vitiating the goal of this mailing
> list. It would be wonderful if you could back up the monomaniacle
> inclination toward 'dselect' in your last three statements with some
> explanation. I'm looking for information on dpkg, not dselect. If I
> absolutely must use dselect, I would like to know why, and what
> functionality it provides to Debian that dpkg (or one of the dpkg
> utilities such as 'dpkg-deb') does not. I'm doing this to learn, and
> using the base tools for debian package management will inherently tell
> me how dselect works.
It was meant to give aid, not offense. If you took it as such, please
accept my apology. My point was however, that you would not have
run into these problems if you had walked between the lines, which
you would have if you had used the high level interface for package
management that debian provides. It is called dselect, not dpkg-deb.
This is documented in the dpkg(8) manual page.
But please don't let me discourage you from learning the way things work.
> >When you only "remove", and later reinstall, your original configfiles
> >will still be inplace. That is, unless you have removed some of these
> >files while the package was removed, then it will not put a new configfile
> >in if it finds that the old one is gone. This is just like when upgrading
> >an installed package: if you removed a configfile on the old version,
> >you don't expect it to reappear after upgrade.
> >
> Sounds good. It looks like the reason dpkg removed those 'dpkg-new'
> files was because dpkg found the package was already installed. This
> was because it was never purged, only removed. I will attempt to purge
> everything, and then install. A purge should remove any list files
> associated with the particular packages, correct? If so, an install (I
> take it you must do an install, not re-install, after purging) should
> re-construct those list files? I certainly hope so.
When a package is removed, but not purged, the "conffiles" remain.
You can see what a package's conffiles are by looking at the output of
"dpkg -s $pkg". If you reinstall the package later, the still existing
conffiles will not be overwritten. If the conffile was removed manually,
then that state of the conffile will not be changed.
When you purge a package, not only will its conffiles be removed, dpkg
will not know that it ever was installed. So if you later reinstall the
package and for some reason some conffile still exists, it will be
overwritten with the default package conffile.
There is also another class of configuration files, those that are not
contained in a deb proper, but are created by installation scripts or
by some other configuration script in the package. Those files are
not registered by dpkg and will not show up when dpkg is used with the
'--listfiles' or '--search' options. The package maintainer scripts
will have to remove these files explicitly when the package is purged.
> >> One way I've found to re-install, is to use `dpkg-deb --extract
> >><filename> /', but that's not good, as it kind of defeats the point
> >>of dpkg, as dpkg is used to not only extract, but to configure things
> >>you install as well, correct? I've also found another way, which is to
> >>remove the list files associated with a program (I think I found them in
> >>/var/lib/dpkg/status/info/* ??). Again, this defeats the point of dpkg,
> >>as dpkg should be a package manager on it's own accord, so I shouldn't
> >>need to be deleting things. Of course, after deleting a bunch of those
> >>list files, dpkg complains whenever I run it that it's missing things.
> >>It would be great if someone could tell me how to repair this as well...
You also have to remove the package's entry from the status database.
If the package uses debconf, you may have to hack into that too.
For correct functioning of the package management system, it is important
to be careful with the administrative database, but also with the actual
installed files. If a file is moved out of the way, it is out of dpkg's
sight. It would be very hard to make it do otherwise. Well, actually you
can, with dpkg-divert, but it relates to "mv" as dpkg --unpack relates to
"tar".
> >Please, for your own sake, do not hack into the package management system
> >at this level, until you have read all the documentation, in which case
> >the above explanation would have been more evident from the start.
> >
> Yes, I'll make sure I've read all the dpkg documentation.
Just scaring you a bit there. It's not very evident, really.
The debian package management system on a whole is quite complex.
Apart from the dpkg(8), dpkg-deb(8) and deb(5) manpages, the documentation
is a bit scattered, but you can find bits and pieces in the debian policy
guide and in /usr/share/doc/debian/FAQ/index.html, it is in doc-debian.
And don't forget to look at the documentation section of the excellent
debian website.
Cheers,
Joost
Reply to: