Hello all,
one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ?
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for not doing this ? I can't think of any...
If this is a good thing, then we should do this NOW, not when it's too late.
The current drawbacks are just too much IMHO.
Andreas Mohr
On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote:
Hello all,
one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ?
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for not doing this ? I can't think of any...
If this is a good thing, then we should do this NOW, not when it's too late.
The current drawbacks are just too much IMHO.
Why not put them in /usr/lib/wine/ as suggested by the FHS?
Ciao, Marcus
On Fri, 23 Feb 2001, Marcus Meissner wrote:
Why not put them in /usr/lib/wine/ as suggested by the FHS?
That's what I've been doing for the FreeBSD port for ages.
Welcome to the club! :-)
Gerald
On Fri, Feb 23, 2001 at 01:29:29PM +0100, Marcus Meissner wrote:
On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote:
Hello all,
one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ?
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for not doing this ? I can't think of any...
If this is a good thing, then we should do this NOW, not when it's too late.
The current drawbacks are just too much IMHO.
Why not put them in /usr/lib/wine/ as suggested by the FHS?
Hmm, yes that's one solution.
However this doesn't solve naming conflicts, does it ? If we have libole and another project (was it gnumeric ?) uses the same name, then there really is nothing to our defense. If we choose to use libwine_xxx or something similar, then the other project looks pretty stupid if it somehow decides to choose the same name (which won't happen anyway).
Putting the libraries in /usr/lib/wine instead seems to only solve the "easy uninstall" problem.
Andreas Mohr
On Fri, 23 Feb 2001, Andreas Mohr wrote:
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for not doing this ? I can't think of any...
Any reason for doing this? I can't think of any...
The Debian packages work perfectly, without any potential for conflict. They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from /usr/lib (and Wine's own configure adds rpath stuff last time I looked)
On Fri, 23 Feb 2001, Ove Kaaven wrote:
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for doing this? I can't think of any...
The Debian packages work perfectly, without any potential for conflict. They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from /usr/lib (and Wine's own configure adds rpath stuff last time I looked)
The Red Hat package does the same thing, but still I'd prefer renaming the libraries for all the people who compile from source without knowing all the details.
You quickly get from "I'm a total newbie" to "I'm still a newbie, but I know that basics and I've figured out I can install almost any program from source by just typing "./configure --prefix=/usr; make install"!" state. We shouldn't kill those users' normal libraries. [Yes, I know users should in theory put all their stuff to /usr/local, but I haven't seen many people who actually do]
Either rename them, or make configure intelligent enough to do /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly told not to do it...
LLaP bero
On Fri, Feb 23, 2001 at 03:47:39PM +0100, Bernhard Rosenkraenzer wrote:
On Fri, 23 Feb 2001, Ove Kaaven wrote:
AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time...
Any reason for doing this? I can't think of any...
The Debian packages work perfectly, without any potential for conflict. They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from /usr/lib (and Wine's own configure adds rpath stuff last time I looked)
The Red Hat package does the same thing, but still I'd prefer renaming the libraries for all the people who compile from source without knowing all the details.
You quickly get from "I'm a total newbie" to "I'm still a newbie, but I know that basics and I've figured out I can install almost any program from source by just typing "./configure --prefix=/usr; make install"!" state. We shouldn't kill those users' normal libraries. [Yes, I know users should in theory put all their stuff to /usr/local, but I haven't seen many people who actually do]
Either rename them, or make configure intelligent enough to do /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly told not to do it...
Exactly. Renaming them is *much* cleaner.
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 ;-)
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".
It will fail. Somewhere. Sometime.
Andreas Mohr
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
-
admiral coeyman -
Andreas Mohr -
Bernhard Rosenkraenzer -
Gerald Pfeifer -
Marcus Meissner -
Ove Kaaven