[Aptitude-devel] Bug#501588: aptitude should remove/purge packages before any upgrades/installs

Wed May 4 19:08:36 UTC 2016

Control: severity -1 wishlist
Control: tags -1 + wontfix
Control: close -1

Hi,

2008-10-08 17:53 Jameson Graef Rollins:
>Package: aptitude
>Version: 0.4.11.8-1
>Severity: normal
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Aptitude should give priority to removing and purging packages before
>handling any other package installs or upgrades.  In this way, things
>can be cleared out, space can be made, and complexity reduced for any
>operations that follow.
>
>This came up for me today when /usr became full during an upgrade.
>Because /usr filled up, the upgrade failed, leaving the system in a
>broken state, including leaving packages unconfigured and dependencies
>uninstalled.  However, aptitude kept trying to fix the dependency
>problems whenever I tried to purge packages to free up space, trying
>to do any of the fixes before the purges, which of course continually
>failed because there was no space in /usr.  If aptitude had purged all
>requested packages *before* attempting any fixes, then there would
>have been space for the fixes and they would have succeeded.  Not to
>mention that the removals/purges could potentially simplify any
>dependency calculations needed for the fix.  Ultimately I had to
>remove all of the packages with unmet dependencies inorder for things
>to get fixed, which is obviously not ideal.
>
>It also in general just seems to me to make more sense to do any
>removals and purges first since it reduces the overall complexity and
>storage needs of the system, therefore only simplifying whatever
>operations might follow.
>
>Thanks for maintaining such a key component to Debian.
>
>jamie.

2008-10-23 12:41 Jens Seidel:
>Hi,
>
>I agree with this bug. Cleaning up the package database before
>installing new packages is a good idea.
>
>I now got the following problem which demonstrates this as well:
>
>(Reading database ... 249817 files and directories currently installed.)
>Unpacking libgts-0.7-5 (from .../libgts-0.7-5_0.7.6+darcs080704-2_i386.deb) ...
>dpkg: error processing /var/cache/apt/archives/libgts-0.7-5_0.7.6+darcs080704-2_i386.deb (--unpack):
> trying to overwrite `/usr/lib/libgts-0.7.so.5.0.1', which is also in package libgts-snapshot
>dpkg-deb: subprocess paste killed by signal (Broken pipe)
>Errors were encountered while processing:
> /var/cache/apt/archives/libgts-0.7-5_0.7.6+darcs080704-2_i386.deb
>E: Sub-process /usr/bin/dpkg returned an error code (1)
>A package failed to install.  Trying to recover:
>dpkg: dependency problems prevent configuration of k3d:
> k3d depends on libgts-0.7-5 (>> 0.7.6); however:
>  Package libgts-0.7-5 is not installed.
>dpkg: error processing k3d (--configure):
> dependency problems - leaving unconfigured
>Errors were encountered while processing:
> k3d
>
>I installed from
>
># Gerris (GNU Flow)
>deb http://gts.sourceforge.net/debian/ ./
>deb http://gfs.sourceforge.net/debian/ ./
>
>the package gerris-snapshot which depends on libgts-snapshot.
>Later I tried from the official Debian mirror to install libgts
>to fullfil a dependency. But libgts conflicts with libgts-snapshot
>because they have a common file so I just tried to solve this problem
>by deselecting libgts-snapshot. This resulted in the error above.
>
>I'm not sure whether there exists other scenarios where a conflict is
>only avoided if one removed packages at the last step but if it doesn't
>matter doit as soon as possible.

aptitude doesn't decide the order in which the individual actions are
taken.  This is decided between (lib)apt and dpkg when aptitude passes
the information about what the user asked aptitude to do, from a high
level perspective.

Sometimes the ordering of actions depends on the interdependency of
packages to be upgraded/removed/installed, and the ones in the system at
a given time, it's not a straightforward solution.

Even if it was possible, purging all packages first is not necessarily
the best of decisions or wouldn't solve problems in all cases.  What if
it purges a critical component (say, grub1), while it cannot install the
replacement (say, grub2) because something else fails in between?

In this case, if they conflict, it would be better to try to deinstall
grub1 only immediately before installing grub2, so as to minimise the
amount of things that can go wrong in between.  Similar if one switches
between components that would benefit from a minimal amount of downtime
(e.g. mail or web servers, syslog-daemons).

Also, in general upgrades always take more space, and very seldomly free
space.  If one has only 10 free MB and the upgrade needs 50MB or more of
extra space (a very down-to-earth / conservative number), it is unlikely
that removing some packages first is going to allow the whole upgrade to
succeed.  It can help in some cases, but it's not a guarantee in any
case.

Lastly, see #397728 for a bug request asking the contrary.

In summary, this is a very complex matter, not a simple thing to
address, and there are reasons to do the contrary.  But in any case,
since aptitude doesn't decide this, I am going to close the bug report
as +wontfix, because reallistically we are not going to be able to do
anything about this, and keeping it open indefinitely does not make
sense.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>