huge library renaming ?
admiral at corner.net
Sat Feb 24 00:25:00 CST 2001
> 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.
> 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
May you live as long as you wish and age but a single day.
[Telnet to telnet.corner.net]
More information about the wine-devel