Group,
Sure Debian handles everything perfectly, and sure other distros do the same, but this *will* fail at the user level somewhere e.g. if they want to install the stuff themselves, and e.g. need to uninstall the mess cleanly again. (I know my newbies ;-)
The main problem we'll have is always going to be on the user end. We're trying to get windows applications ported, thus we have to make the porting as painless for windows programmers as we can. Wine must be set up in the way that is simplest for the end user. If we plan this out properly, then wine will make porting easier that the complexities of using wine. Otherwise, wine will not be used. Renaming the libraries is the simplest solution. Even placing them in a custom directory, the user must take action to avoid name conflicts. That's additional work on the user end which adds to the learning curve. Is it reasonable to expect the end user to use rpath?
Thus I'd rather see this solved in the best way possible. And this is not the current solution IMHO.
I concur.
The libraries are not clearly identified as being win32 stuff or wine stuff. And this is wrong IMHO, regardless of whether "we normally do this or that to avoid problems like that".
Which also makes them hard to remove. I've removed one set of libraries to give me drive space for the next set. We risk becomming like 'other monopolies' if we expect other people to work around problems with wine. Name conflicts are not the user's problem--they are ours. I've worked with dll conflicts just like this with a pair of HP devices under windows. End users wouldn't put the time into finding conflicts that we put into tracking that down....
It will fail. Somewhere. Sometime.
And the less total the failure, the harder the source will be to find.... -Robert 'Admiral' Coeyman