Debian Bug report logs - #9955
dpkg eats available filename if unpack fails

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Andy Mortimer <andy.mortimer@poboxes.com>

To: submit@bugs.debian.org

Subject: dpkg eats available filename if unpack fails

Date: Mon, 19 May 1997 15:13:59 +0100

Package: dpkg
Version: 1.4.0.17

I'm not really sure if this is a bug or not, so do feel free to correct
me! If an error occurs with dpkg --unpack (or in the equivalent stage of
dpkg --install), then all details about the package filenames are removed
from the available database. I couldn't actually find the place in the
source where this happened after a quick look, but I don't really have
the time or the inclination to delve deeply into it; the debugging
output didn't seem to show anything useful, though.

I can see the use of doing this -- if a package doesn't unpack, there's
very little point in trying again -- but this is not always true, for
example the Netscape wrapper package or the teTeX packages, both of which
depend on something in the existing filesystem in order for the preinst
to succeed.

This has been the source of two bug reports against dpkg-mountable (#8054
and #9375, merged), which is why I bring it up. It would be fairly easy
for me to keep local copies of the available files databases, and use
them instead, but this seems rather hacky and suboptimal.

There follows an example of this, in case my description wasn't clear
enough.

Cheers,

&E

-- 
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
I found myself alone, alone above a raging sea
That stole the only girl I loved and drowned her deep inside of me.

root@asm21:~# dpkg --print-avail no-unpack
Package: no-unpack
Maintainer: Andy Mortimer <real-asm21@asm21.emma.cam.ac.uk>
Architecture: all
Version: 0.0.1
Filename: local/no-unpack.deb
Size: 1034
MD5sum: 23a13fdd613f7ba5e47863c8de754e75
Description: Package that won't unpack
 For testing purposes only, fairly obviously.

root@asm21:~# dpkg --install /root/debian/local/no-unpack.deb
(Reading database ... 32636 files and directories currently installed.)
Unpacking no-unpack (from .../debian/local/no-unpack.deb) ...
dpkg: error processing /root/debian/local/no-unpack.deb (--install):
 trying to overwrite directory /cdrom' in package base-files with nondirectory
Errors were encountered while processing:
 /root/debian/local/no-unpack.deb

root@asm21:~# dpkg --print-avail no-unpack
Package: no-unpack
Maintainer: Andy Mortimer <real-asm21@asm21.emma.cam.ac.uk>
Architecture: all
Version: 0.0.1
Size: 1034
Description: Package that won't unpack
 For testing purposes only, fairly obviously.

Message #10 received at 9955@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: control@bugs.debian.org, 9955@bugs.debian.org

Subject: 9955 bug or feature?

Date: 07 Oct 2002 20:41:41 +0200

Is this a bug or a feature?

> If an error occurs with dpkg --unpack (or in the
> equivalent stage of dpkg --install), then all details
> about the package filenames are removed from the
> available database.

If this isn't a bug then this report should be downgraded or closed.

--
Thomas Hood

Message #17 received at 9955-done@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Andy Mortimer <andy.mortimer@poboxes.com>, 9955-done@bugs.debian.org

Subject: Re: Bug#9955: dpkg eats available filename if unpack fails

Date: Thu, 14 Aug 2014 13:13:40 +0200

Hi!

On Mon, 1997-05-19 at 15:13:59 +0100, Andy Mortimer wrote:
> Package: dpkg
> Version: 1.4.0.17

> I'm not really sure if this is a bug or not, so do feel free to correct
> me! If an error occurs with dpkg --unpack (or in the equivalent stage of
> dpkg --install), then all details about the package filenames are removed
> from the available database. I couldn't actually find the place in the
> source where this happened after a quick look, but I don't really have
> the time or the inclination to delve deeply into it; the debugging
> output didn't seem to show anything useful, though.
> 
> I can see the use of doing this -- if a package doesn't unpack, there's
> very little point in trying again -- but this is not always true, for
> example the Netscape wrapper package or the teTeX packages, both of which
> depend on something in the existing filesystem in order for the preinst
> to succeed.

This was a bug indeed, but it got fixed as a side-effect in dpkg 1.17.11
which does not write to the available file any longer on unpack. Thus
closing.

Thanks,
Guillem

Send a report that this bug log contains spam.