Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 39369 - mono and pnet conflict
Summary: mono and pnet conflict
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: dotnet
Depends on:
Reported: 2004-01-25 11:28 UTC by Matthew Swank
Modified: 2005-01-18 08:39 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

pnet ebuild with init.d stuff and mono block removed (pnet-0.6.8.ebuild,860 bytes, text/plain)
2004-08-08 03:36 UTC, Rainer Größlinger (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Swank 2004-01-25 11:28:53 UTC
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:
Comment 1 Rainer Größlinger (RETIRED) gentoo-dev 2004-01-25 14:03:58 UTC
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 :)
Comment 2 Todd Berman (RETIRED) gentoo-dev 2004-01-25 15:36:56 UTC
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. 
Comment 3 Matthew Swank 2004-01-25 17:48:25 UTC
ilasm is an executable in pnet, ilasm in mono is a script that runs ilasm.exe I believe
Comment 4 Todd Berman (RETIRED) gentoo-dev 2004-01-25 17:52:50 UTC
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 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.
Comment 5 Matthew Swank 2004-01-25 18:46:05 UTC
Wouldn't something like "dotnet-config" be appropriate; something to keep track of which dotnet implementation is in use.
Comment 6 Rene Androsch 2004-02-07 01:53:32 UTC
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!
Comment 7 Patrizio Bassi 2004-07-03 10:18:32 UTC
still nothing here? nothing to make both usable?
Comment 8 Rainer Größlinger (RETIRED) gentoo-dev 2004-07-17 04:52:10 UTC
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.
Comment 9 Rainer Größlinger (RETIRED) gentoo-dev 2004-08-08 03:36:37 UTC
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.
Comment 10 Patrizio Bassi 2004-10-09 03:51:52 UTC
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!

Comment 11 Rainer Größlinger (RETIRED) gentoo-dev 2004-10-09 04:14:54 UTC
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.
Comment 12 Radek Podgorny 2004-12-06 15:14:12 UTC
I'm also interested in this... What about submitting it with hard-mask?
Comment 13 Rainer Größlinger (RETIRED) gentoo-dev 2005-01-01 06:35:18 UTC
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!
Comment 14 Rainer Größlinger (RETIRED) gentoo-dev 2005-01-16 01:51:48 UTC
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.
Comment 15 Radek Podgorny 2005-01-18 07:41:20 UTC
Can you please remove the mono->pnet !depend...? This should be a matter of seconds. Thanks...
Comment 16 Rainer Größlinger (RETIRED) gentoo-dev 2005-01-18 08:39:25 UTC