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 <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
