I do not consider it acceptable that certain pairs of packages cannot be installed together (i.e. block each other) for no other reason than installing a file of the same name (usually the program's main binary in /usr/bin). This is the case at least for
* app-misc/gnuit and dev-util/git[gtk], both installing /usr/bin/gitview
* dev-lang/swi-prolog and media-libs/ploticus, both installing /usr/bin/pl
It would be easy to resort to alternative names before installing such files. E.g. I have seen swi-prolog on other systems (forgot which ones) before, where the binary was named "swipl". The ebuild of package A could output a warning message that for reasons of compatibility with package B the file F was renamed to G, that should be very easy to realize. IMHO this should be the case for all cases of a similar triviality in the standard portage tree. Of course there may be harder cases (with multiple filename collisions), and of course other overlays are not within your responsibility.
Sorry if this has been reported before; I could not find a bug on the general case, only one on swi-prolog vs. ploticus (bug 234849), which was apparently "resolved" by introducing a mutual block :-( However, I seriously hope that this is not a WONTFIX issue.
Steps to Reproduce:
Try to install two mutually exclusive packages, e.g. the ones mentioned above.
Packages block each other for a reason that is understandable but not really rational.
Packages can be installed, possibly leading to some files having non-standard names to resolve collisions
The problem is that other packages might rely on the names of those files. For example games-util/qstat and sys-cluster/torque both install /usr/bin/qstat. But you can't rename any of them. games-util/xqf wants qstat from games-util/qstat and renaming sys-cluster/torque's qstat would at least break upstream's documentation. So it's basically a WONTFIX.
(In reply to comment #0)
> It would be easy to resort to alternative names before installing such files.
> E.g. I have seen swi-prolog on other systems (forgot which ones) before, where
> the binary was named "swipl". The ebuild of package A could output a warning
> message that for reasons of compatibility with package B the file F was renamed
> to G, that should be very easy to realize.
Examples of how this should IMHO be done follow. I see that each package handles this issue in an idiosyncratic way. Maybe there should even be a standard procedure introduced into portage.
* sci-visualization/paraview-3.6.1-r1 (renaming the binary and giving a warning message -- excellent!)
* sci-biology/plink-1.06 (rename only, in accordance with Debian)
* dev-tex/tex4ht (does not install certain files, gives instructive elog output)
* sci-astronomy/wcstools-3.7.7 (rename)
* net-mail/courier-imap-4.6.0 (rename with prefix)
* media-sound/mp3blaster-3.2.5.ebuild (rename)
* net-analyzer/argus-2.0.6 (does not install one colliding file, IMHO not much better than a block)
* dev-lang/mono/mono-22.214.171.124 (deletes some non-critical files)
* mail-mta/courier/courier-0.62.2 (rename with prefix)
* dev-python/epsilon/epsilon-0.5.11 (rename with prefix)
Further related bugs:
* bug 249423 (sci-visualization/extrema and sci-chemistry/psi provide /usr/bin/extrema -- "fixed" by block)
* bug 279018 (dev-util/diffuse and sci-chemistry/tinker provide /usr/bin/diffuse -- "fixed" by block)
* bug 247812 (dev-ruby/amrita and media-sound/ams provide /usr/bin/ams -- "fixed" by block)
* bug 207534 (media-gfx/tic98-1.01-r1 and media-libs/netpbm-10.40.0 provide /usr/bin/pbmclean -- OK, but those two binaries probably have the same functionality)
* bug 281191 (games-mud/crystal-0.2.2 and x11-misc/xscreensaver-5.08-r2 provide /usr/share/man/man6/crystal.6.bz2 -- fixed by rename)
* bug 90089
* bug 288038 (fixed by rename)
I don't think it is possible to come up with a generic solution (but feel free to prove me wrong). Having blockers on packages at least is a better situation than silently overwriting files from another package.
In those cases where someone really needs both packages installed we should look for a solution that makes sense in the context of those packages, e.g. taking the situation that Sebastian describes into account.
(In reply to comment #2)
Further positive example: git vs. gnuit has also been solved by rename, see bug 287863
Nothing is going to happen on this bug. If you have specific cases you want fixed, and have a way to fix it, file individual bugs for the maintainers of those packages.