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