* Detected file collision(s): * * /usr/bin/csc * /usr/bin/csi * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-lang/mono-5.4.1.6:0::gentoo * /usr/bin/csc * /usr/bin/csi * * Package 'dev-scheme/chicken-4.10.0-r1' NOT merged due to file ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-gnome_libressl-test_20180117-214426 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.2.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python3.6 (fallback) [3] python2.7 (fallback) java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.6.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm emerge -qpv dev-scheme/chicken
Created attachment 516648 [details] emerge-info.txt
Created attachment 516650 [details] dev-scheme:chicken-4.10.0-r1:20180125-102358.log
Created attachment 516652 [details] emerge-history.txt
Created attachment 516654 [details] etc.portage.tbz2
Created attachment 516656 [details] logs.tbz2
Well, I guess there's nothing we can do about it, right? Renaming csc and csi binaries from chicken would be deviation from upstream. I think not so many people have the two installed at the same time anyway.
I agree with Maxim that this is a difficult problem to solve without contradicting upstream's naming conventions. I am curious, though, as to what the standard Gentoo procedure is in this situation. Do we mark mono as a blocker in the Chicken ebuild? I couldn't find anything in the Development Guide, nor do I know off the top of my head other packages which may have "solved" this issue. Would it be fair-game to find out what other distros do in this situation and follow their lead?
Regardless of either renaming in the Gentoo-land or convincing on of the involved 2 upstream parties I'd add a blocker in the meanwhile.
I am also affected by this bug (one of those not so many people :) ).
Should this be a duplicate of https://bugs.gentoo.org/679058 ? (or the other way around)
Also affected by this. Here is the related mono issue which has links to a number relevant debian bugs. https://github.com/mono/mono/issues/9056 There is no good solution here. Both communities aren't going to budge on this. It might be nice to have a general system in place for cases like this where it is clear that there is simply going to be a name conflict. The idea of having something like a secondary chroot install location where packages with name conflicts could be installed seems like it might be one option. Another simpler option might be to simply have a /usr/conflicts/ path where /usr/conflicts/{package-name}/ could be used to sandbox specifically conflicting files e.g. /usr/conflicts/dev-scheme/chicken/usr/bin/csc. The user would then be able to adjust their path to run the mono C# compiler vs the chicken scheme compiler depending on their needs. This wouldn't work for all types of conflicts, but many/most of the other conflicts can be patched out more easily because they aren't user facing in the same way files in /usr/bin are.
Is there a way to use eselect for this?
*** Bug 657916 has been marked as a duplicate of this bug. ***
*** Bug 679058 has been marked as a duplicate of this bug. ***
