Your message dated Thu, 14 Aug 2014 13:13:40 +0200
with message-id <[email protected]>
and subject line Re: Bug#9955: dpkg eats available filename if unpack fails
has caused the Debian Bug report #9955,
regarding dpkg eats available filename if unpack fails
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
9955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=9955
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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, [email protected]
http://www.netforward.com/poboxes/?andy.mortimer
Finger [email protected] 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 <[email protected]>
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 <[email protected]>
Architecture: all
Version: 0.0.1
Size: 1034
Description: Package that won't unpack
For testing purposes only, fairly obviously.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
