* 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. ***
Chicken Scheme has the same problem on Windows. According to the Chicken Scheme wiki, the recommended solution is to change %PATH% based on the current project, or rename the chicken-csc program. The suggestion of manipulating the PATH does not work, as on Linux it hardcodes all the paths, so when you call chicken-install, it fails to find the correct compiler. To facilitate renaming programs, the chicken build system supports defining C_CSC_PROGRAM and C_CSI_PROGRAM to set the names of csc and csi used by the rest of chicken-scheme (notably chicken-install). Setting PROGRAM_PREFIX="chicken-" before invoking the ebuild (via package.env or similar) would let the package install, except it fails in src_install because the modules.db path needs to reflect the same prefix, which requires patching the ebuild. Also the prefix is applied to all chicken programs, so the main executable becoems chicken-chicken, and so on. Alternatively, chicken's defaults.make can be patched to set just C_CSC_PROGRAM and C_CSI_PROGRAM to include the prefix. Notably, all the other chicken-related programs are already prefixed, so external libraries generally don't need further adjustments, as their main entry points are usually either `chicken` or `chicken-install`, both of which work properly with this modification. This could be implemented via a USE flag fairly easily, but there would probably be no harm in always applying it. I did a bit of digging for other packages in a similar position, and found games-misc/bsd-games, which renames /usr/bin/monop to /usr/bin/monop-bsd to also avoid conflicting with dev-lang/mono, unconditionally.
