Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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.