[Bug 5461] New: Fix Wine install

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=5461

           Summary: Fix Wine install
           Product: Wine
           Version: CVS
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P4
         Component: wine-misc
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: chris.kcat at gmail.com


Not sure whether to file this under critical/major or enhancement, so I went 
with the safer bet.

There's a problem with the way Wine installs itself and creates a "default" 
Windows install. Basically, when you upgrade an existing Wine install that has 
a ~/.wine directory, any new, changed, or removed files that go into Drive C 
will not be carried over. This is because Wine only installs certain DLLs and 
EXEs when ~/.wine is created, but for upgrades, it's already there. I wouldn't 
doubt this is causing many obscure problems.

The only way to remedy this is to delete your ~/.wine directory and have Wine 
create a new one. However, this comes at the nasty cost of wiping all your 
Wine settings, the registry, and most Windows program settings. A good number 
of Windows apps won't run if registry entries that were created at program 
installation aren't there, meaning they need to be reinstalled and 
reconfigured. Any and all DLLs previously installed and not provided by Wine 
need to be reinstalled as well.

I'm not sure of the exact details to go about this, but a possible solution 
may be to put DLLs and EXEs into $PREFIX/lib/wine (instead of in the 
~/.drive_c/windows/ heriarchy), map / to Z: by default (already done, AFAIK), 
and add Z:$PREFIX/lib/wine to the default Windows PATH setting.

Though this might not work for programs that expect stuff in C:\windows. 
Another option may be to make use of /opt, which is for programs that rely on 
their own directory structure. /opt/wine and installed files could be given 
mode 775/664 and owned by root:wine (so "Administrator accounts" would be 
users in the 'wine' group, and "Limited acocunts" wouldn't be). The drive 
assignment symlinks would be somewhere in /opt/wine (eg. /opt/wine/dosdrives), 
and the default Drive C would be made with make install, instead of first run. 
As long as it only installs missing/newer files (and doesn't delete existing 
stuff), this would ensure new files are installed and modified files are 
updated, without having to behave as if you just reinstalled Windows.

A third, less drastic, option may be to include a script that copies the 
proper files to the ~/.wine/dosdrives/c:/windows heriarchy. Something that 
could be run after make install, and wouldn't change any existing settings or 
delete existing files. The end of make install would alert the user that 
people upgrading should run the script to update wine user files (with a 
warning to *NOT* run it as root). In addition, you could make it so that when 
wine is run and detects the current version is different than the last run 
version, it invokes that script automatically before the Windows program is 
run (CVS users would still need the script though, since CVS updates don't 
always change the version number).

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.