Handling File Collisions Between Blocking Packages

Blocker Conflicts

If one package blocks another package, the two packages conflict such that they cannot be installed simultaneously. These conflicts are often due to file collisions. In some cases, packages that block each other can be temporarily installed simultaneously. In order to resolve file collisions that occur between two blocking packages that are installed simultaneously, the overlapping files must be removed from the contents list of the package which was installed first.

Some cases may exist such that temporary simultaneous installation of blocking packages will cause some sort of problem. However, this type of solution will only be chosen for blockers that can not be satisfied in any other way, such as by simple adjustment of merge order. In addition, this type of solution will not be chosen if a blocking package will overwrite files belonging to packages from the system set, or packages that are runtime dependencies of Portage itself. These constraints serve to limit the probability that a chosen solution will cause an unforeseen problem.

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

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

Calculating dependencies... done!
[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"
[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

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!
[nomerge      ] sys-apps/coreutils-6.11 [6.9-r1] USE="acl nls xattr (-selinux) -static -vanilla%"
[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
[ebuild     U ] sys-apps/coreutils-6.11 [6.9-r1] USE="acl nls xattr (-selinux) -static -vanilla%" 0 kB

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

10 thoughts on “Handling File Collisions Between Blocking Packages”

  1. Nice one! This has been on my wish list for *ages*; is it actually uninstalling the packages in that output, or just the colliding files?

  2. It does a normal uninstall. The colliding files are removed from the contents of the old package when the first one is merged though, so those files don’t get uninstalled.

  3. Hmm ok; seems a bit unnecessary if the new pkg is going to be installing the same file, or is this something to do with having them both on system during upgrade?

    Well done for getting the automatic uninstall, man, and thanks from someone who’ll save a lot of time as a result.

  4. In some cases, the smoothest way to perform an upgrade is to merge the new package files into place and then remove any files that belong to the old package (only the ones that do no overlap with the new package). That’s how portage has always done it for normal upgrades within a package slot.

    Now, in some cases, we have similar behavior with packages that block each other, so the “smooth upgrade” process is no longer confined to a single package slot. The process can be spread over multiple packages that block each other.

  5. Heh, I remember some dev mentioning that as a feature he’d really like; in place upgrade for blockers in exactly the manner you describe: only unmerge old when new is about to be installed (ie after successful compile.) Nice work.

  6. It seems like the process, of installing the new package then removing the old one, should still work. Are there some situations where that is just a bad assumption?

    And thanks for looking at that, definitely an itchy spot there.

  7. Indeed, some cases may exist such that temporary simultaneous installation of blocking packages will cause some sort of problem. However, the solver will only choose this type of solution for blockers that it is not able to satisfy in any other way, such as by simple adjustment of merge order. In addition, it will not choose this type of solution if a blocking package will overwrite files belonging to either of the following types of packages:

    • Those that belong to the system set.
    • Required runtime dependencies of portage itself.

    The above constraints serve to limit the probability that the chosen solution will cause some sort of problem. If testing shows that these constraints are not sufficient to separate good solutions from bad solutions in a significant number of cases, then we will have to devise additional constraints if possible, or else extend blocker syntax to indicate which type of solution is appropriate for a given blocker relationship.

  8. Just came here via the GMN and that’s really great! I recently had my first look into portage’s source code (after years of using it) and it’s great to see the work you do – and some long wanted features materialize.

    I tried both pkgcore and paludis, and while they are nice in their own ways, I just feel more comfortable with portage on production machines, and I’m very glad it’s getting some love, too. Keep up the good work!

  9. I’m confused…

    Just saw this referenced in GMN, looks fantastic, but after a sync, emerge -s only offers portage 2.1.4.4 as listed… I have that version installed, and it doesn’t do blocker removal.

    When/where do we get Portage 2.1.5?

    ART

  10. You can unmask portage-2.1.5* like this:

    echo "=sys-apps/portage-2.1.5*" >> /etc/portage/package.keywords

    See the Test Particular Versions part of the Handbook for more information about keywords.

    Portage 2.1.5.4 is probably good enough to be marked stable but it needs a couple more weeks of testing first.

Comments are closed.