mono and pnet have two identical, mutually incompatible files that cause the ebuilds to block each other: /usr/bin/ilasm and /usr/man/man1/ilasm.1.gz The biggest problem this causes is that it makes it impossible to use gtk-sharp and pnet simultaneously under Gentoo Mandrake deals with this by renaming ilasm to ilasm-mono and ilasm.1.gz to ilasm-mono.1.gz couldn't we do something similiar? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Some distributions block those packages (like we do) others rename the conflicting files. I disagree with the proposal (someone else made some months ago) to use ilasm-mono and ilasm-pnet and make ilasm itself a symlink to one of those (that'll introduce many problems for people using both and not knowing how that is handled), but that just as a side node. I am happy if mono's ilasm is renamed, but since mono introduced that problem in unix-land (they were already told x times but they seem to refuse to resolve it), let's hear what our main mono guy thinks about this idea, those are just my two euro-cents :)
I guess im the main mono guy ;) I wasnt aware that mono introduced the problem, but I will leave that bit of history for another discussion. Here is the problem. Many 3rd party compilers assume and expect that ilasm is named ilasm, changing that will break their expectation (this is a windows based file name dependency). So changing ilasm to ilasm-mono is completely and totally unacceptable in my book. As for running gtk-sharp and pnet at the same time, you might find more than a filename blocker as an issue, as pnet has been notoriously unable to run complex gtk-sharp applications (again, a flame war we can have another time). Out of curoisity, is pnet's /usr/bin/ilasm a shell script or a real PE executable? not sure personally. I think the block needs to stay in place at least for a bit longer, and we need to figure out if there is an intelligent easy way around the problem.
ilasm is an executable in pnet, ilasm in mono is a script that runs ilasm.exe I believe
Ive spoken to miguel in the past about this, and to jackson (mono's ilasm author/maintainer) today and I really dont think mono will *ever* change ilasm's name. And I can absolutely understand why. Mono is meant to be compatible with ms.net in as many ways as possible, and other compiler's running thinking ilasm will be there is an important piece of this. I'm inclined to agree and support the block staying in place for right now, unless we can come up with a way that guarentee's that ilasm will always work somehow. and symlink's are an *ugly* way to do this.
Wouldn't something like "dotnet-config" be appropriate; something to keep track of which dotnet implementation is in use.
100 points for the "dotnet-config" thingy! That's the way to doit! We have it for java, opengl, ... so why not for dotnet stuff :) then it makes sense to have ilasm-mono and ilasm-pnet and the dotnet-config just creates symlinks, or copies the files, what ever is needed :) Nice solution!
still nothing here? nothing to make both usable?
ok, I think we really should fix this, I am not quite sure how, though :) (btw. the is another conflicting file /usr/bin/al just for the sake of completion ;) Writing a bash script called dotnet-config and make both packages depend on it and deal with symlinks or copy the files sounds like the best solution to me, but that'll probably give some update pains (since all people who currently have pnet and mono installed would need to remerge a new revision so that the packages itself don't own /usr/bin/ilasm anymore). Renaming the files in question is another option but then we have the problem what package keeps its original name or if we rename both it may confuse some people since there is no "ilasm" (and effectively break some scripts). We should probably go for a dotnet-config (and that package owns the files in question) and symlink/copy appropriate). I am curious what others think about this and even more, who is willing to work on this since we need some compatibility crap inside the script (for people that already have mono or pnet installed when merging dotnet-config for example). Btw. we could also move some files (like the init script and conf thing) to dotnet-config once it's finished, that'll clean up the mono and pnet ebuild a bit.
Created attachment 37013 [details] pnet ebuild with init.d stuff and mono block removed The attached ebuild of pnet can be used for testing parallel installation of pnet and mono. It has the init.d stuff removed (which would go into the dotnet-config package then) and the mono block is also gone. This is just for the purpose when work starts on dotnet-config to have an ebuild outside the tree that can be tested for the pnet side of things.
why this new ebuild has not been committed to portage? no news from the dotnet-config script? shouldn' be so difficult, java and gcc ones are much more complicated!
That ebuild isn't in portage because it is "how it should look with the block removed"...I just attached it in case someone who doesn't use pnet but wants to start working on such a thing can have a pnet ebuild to test.
I'm also interested in this... What about submitting it with hard-mask?
Since most ebuilds in portage are "hardcoded" to depend on mono even if they worked with pnet and additionally mono currently being much more popular I'd propose that with the next release of pnet (end of january) that block is lifted and the conflicting file names will be renamed with a .pnet suffix. So they can safely be installed in parallel and in case someone ever finishes something like "dotnet-config" it can be un-done again. I think that would affect /usr/bin/ilasm and /usr/bin/al (+ man pages etc.), not sure if those are all but I will check...Also, a lot of people probably don't use them anyway, so I really think it's time to make those two packages installable in parallel!
Version 0.6.12 of Portable.NET was released today (ebuilds committed a few minutes ago) and it doesn't have a block on mono anymore, all conflicting files are now renamed with a .pnet suffix: ilasm(+man page), resgen(+man page), al It doesn't conflict with mono anymore (also tested with FEATURES="collision-protect"). The original report is FIXED as soon as the mono ebuilds have the block removed, it would perhaps be a good idea to open a separate bug with low priority for "dotnet-config" and close this one, then.
Can you please remove the mono->pnet !depend...? This should be a matter of seconds. Thanks...
done.
