Upgrade not completed: but package still there.

[Alan Eugene Davis <adavis@kuentos.guam.net>]

 At least three package upgrades were stalled out because of 
dependency on a newer version of libc5.  For example:

     electra:/home/mercury# dpkg -i mtools*
     (Reading database ... 12149 files and directories currently installed.)
     Preparing to replace mtools (using mtools-2.5.4-1.deb) ...
     Unpacking replacement mtools ...
     dpkg: dependency problems prevent configuration of mtools:
      mtools depends on libc5 (>=5.2.18-4); however:
       Version of libc5 on system is 5.2.18-1.
     dpkg: error processing mtools (--install):
      dependency problems - leaving unconfigured
     Errors were encountered while processing:
      mtools

For example with par I found that the upgraded package version still
ran.  This is in fact a commonly recurring event (feature?): packages
that have been unpacked but not "configured" may actually run,
depending on how sophisticated the setup involved in (and required by
the package) in the configuration.

I think it is especially important that such half installed packages
be backed out.  Isn't this actually supposed to be the case?
Otherewise, I can envision problems where I have tried to upgrade a
package, the upgrade failed because of a depends (which perphaps, like
libc5, I haven't bothered to FTP yet), and I am hung up until such
time as I get around to getting the depended-upon package.  

This is a BUG.  

I would appreciate instructions as to how to back out
of a partially completed REPLACE (upgrade).


Alan Davis

"Look after truth and goodness.  Beauty looks after herself."
                    ---Eric Gill

(What difference does it matter whether the installation script is
SVGA or X or even just a text-based script?  Even dialog seems
somewhat elaborate.  After a few minutes it's over, and you install
what you need.  Look after truth and goodness...