Using Blockers to Automatically Uninstall Unwanted Packages

A while ago I wrote a blog entry about

using blockers to adjust merge order. Now, in
portage-2.1.5,
blockers are also resolved automatically in cases when it makes
sense to uninstall a conflicting package (bug #172812).
This feature should allow automatic resolution of

blocker conflicts in many more cases than previously possible, so Gentoo
users won’t be inconvenienced with the task of resolving them manually.

gtk-doc-am vs. gtk-doc-1.8-r2

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[nomerge      ] x11-libs/gtk+-2.12.9-r2  USE="X cups jpeg tiff xinerama -debug -doc -vim-syntax"
[ebuild  N    ]  dev-util/gtk-doc-am-1.10-r1  0 kB
[blocks b     ] dev-util/gtk-doc-am (is blocking dev-util/gtk-doc-1.8-r2)
[uninstall    ]  dev-util/gtk-doc-1.8-r2  USE="emacs -debug -doc"

Total: 1 package (1 new, 1 uninstall), Size of downloads: 0 kB
Conflict: 1 block

coreutils vs. mktemp

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild     U ] sys-apps/coreutils-6.11 [6.9-r1] USE="acl nls xattr (-selinux) -static -vanilla%" 0 kB
[blocks b     ]  sys-apps/mktemp (is blocking sys-apps/coreutils-6.11)
[blocks b     ] >=sys-apps/coreutils-6.10 (is blocking sys-apps/mktemp-1.5)
[uninstall    ]  sys-apps/mktemp-1.5

Total: 1 package (1 upgrade, 1 uninstall), Size of downloads: 0 kB
Conflict: 2 blocks

10 thoughts on “Using Blockers to Automatically Uninstall Unwanted Packages”

  2. Very cool! The most important improvement for Portage since a long time. That will probably reduce posts in the Portage forum by 10%! 🙂

  4. Actually, with portage-2.1.5 you don’t need to do any /etc/portage/modules configuration to avoid the “Updating Portage cache” thing after sync. Now the default behavior is to use cache directly from the $PORTDIR/metadata/cache/ directory. As mentioned in the release notes, you have to add FEATURES=metadata-transfer to make.conf if you want the old behavior (which you probably don’t).

  5. So you’re unmerging mktemp *before* upgrading coreutils? Sounds like an extremely good way to break a system…

  6. Admittedly, uninstallation of mktemp is a questionable operation. However it’s the only solution given the constraint that two blocking packages cannot be installed simultaneously.

  7. The problem is, that’s not really the constraint… Solving this properly requires extending the blocker syntax to say “it’s ok if you uninstall this after rather than before installing me”. Until that’s an option, automatic block resolution is extremely dangerous.

  8. Thanks for add this feature 😀

    About unmerging mktemp before coreutils, maybe portage could make a package before unmerging it with quickpkg for preventing a great breakage :-/

  9. In the particular case of coreutils and mktemp, it would be safe install the new coreutils first (overlapping with the mktemp package) and then remove any remnants of the mktemp package. In order to express cases like this, we can create a separate type of blocker having this property.

Comments are closed.