Summary: | dev-scheme/chicken-4.10.0-r1 with dev-lang/mono-5.4.1.6 - file collision in /usr/bin/csc /usr/bin/csi | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Scheme Project <scheme> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dotnet, jstein, ostroffjh, scheme, scott |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge-info.txt
dev-scheme:chicken-4.10.0-r1:20180125-102358.log emerge-history.txt etc.portage.tbz2 logs.tbz2 |
Description
Toralf Förster
2018-01-25 16:19:26 UTC
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. *** |