From 2858ac99127110f82b91df85af84e1f2fad53dd6 Mon Sep 17 00:00:00 2001 From: Marcus Meissner Date: Sat, 26 Jun 1999 10:32:50 +0000 Subject: [PATCH] Wrote a small document on how to package WINE for distributors. --- documentation/distributors | 152 +++++++++++++++++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 documentation/distributors diff --git a/documentation/distributors b/documentation/distributors new file mode 100644 index 00000000000..8430020759b --- /dev/null +++ b/documentation/distributors @@ -0,0 +1,152 @@ + A small WINE distribution guide. + +While packaging WINE for one of the Linux distributions I came across +several points which have been clarified yet. Particular a how-to for WINE +packaging distributors is missing. This document tries to give a brief +overview over the rationales I thought up and how I tried to implement it. +(While the examples use "rpm" most of this stuff can be applied to other +packagers too.) + +1. Rationales + +A WINE install should: +a. Not have a world writeable directory (-tree). +b. Require only as much user input as possible. It would be very good if it + would not require any at all. Just let the system administrator do "rpm + -i wine.rpm" and let any user be able to run "wine sol.exe" instantly. +c. Give the user as much flexibility to install his own applications, do + his own configuring etc. +d. Come as preconfigured as possible, so the user does not need to change + any configuration files. +e. Use only as much diskspace as needed per user. + +A WINE install needs: +f. A writeable C:\ directory structure on a per user basis. Applications do + dump .ini files into c:\windows, installers dump .exe, .dll and more into + c:\windows\ and subdirectories or into C:\Program Files\. +g. The .exe and .dll from a global read-only Windows installation to be + found by applications. +h. Some special .dll and .exe files in the windows\system directory, since + applications directly check for their presence. + + +2. Implementation + +2.1 Building the package + +WINE is configured the usual way (depending on your buildenvironment). +The "prefix" is chosen using your application placement policy +(/usr/,/usr/X11R6/, /opt/wine/ or similar). The configuration files +(wine.conf, wineuser.reg, winesystem.reg) are targeted for /etc/wine/ +(rationale: FHS 2.0, multiple readonly configuration files of a package). + +Example (split this into %build and %install section for rpm): + CFLAGS=$RPM_OPT_FLAGS \ + ./configure --prefix=/usr/X11R6 --sysconfdir=/etc/wine/ --enable-dll + make + make install prefix=$BUILDROOT/usr/X11R6/ + install -d /etc/wine/ + install -m 644 wine.ini /etc/wine/wine.conf + +Here we unfortunately do need to create wineuser.reg and winesystem.reg +from the WINE distributed winedefault.reg. This can be done using +./regapi once for one example user and the reusing his .wine/user.reg +and .wine/system.reg files. [FIXME: this needs to be done better] + + install -m 644 winesytem.reg /etc/wine/ + install -m 644 wineuser.reg /etc/wine/ + +You will need to package the files: + $prefix/bin/wine, $prefix/bin/dosmod, $prefix/lib/libwine.so.1.0, + $prefix/man/man1/wine.1, $prefix/include/wine/*, + + %config /etc/wine/* + %doc ... choose from the toplevel directory and documentation/ + +Do not forget ldconfig for the postinstall, the postuninstall and 'rm +libwine.so' for the postuninstall. + +2.2 Creating a good default configuration file + +For the rationales of needing as less input from the user as possible +arises the need for a very good configuration file. The one supplied +with WINE is currently lacking. We need: + +- [Drive X]: + + A for the floppy. Specify your distributions default floppy mountpoint + here. (Path=/auto/floppy) + + C for the C:\ directory. Here we use the users homedirectory, for most + applications do see C:\ as root-writeable directory of every windows + installation and this basically is it in the UNIX-user context. + (Path=${HOME}) + + R for the CD-Rom drive. Specify your distributions default CD-ROM drives + mountpoint here. (Path=/auto/cdrom) + + T for temporary storage. We do use /tmp/ (rationale: between process + temporary data belongs to /tmp/, FHS 2.0) + + W for the original Windows installation. This drive points to the + windows\ subdirectory of the original windows installation. This avoids + problems with renamed 'windows' directories (as for instance 'lose95', + 'win' or 'sys\win95'). During compile/package/install we leave this + to be '/', it has to be configured after the package install. + + Z for the UNIX Root directory (Path=/). This avoids any problems with + "could not find drive for current directory" users occasionaly complain + about in the newsgroup and the ircchannel. It also makes the whole + directory structure browseable. The type of Z should be network, so + applications expect it to be readonly. + +- [wine]: + Windows=c:\windows\ (the windows/ subdirectory in the users + homedirectory) + System=c:\windows\system\ (the windows/system subdirectory in the users + homedirectory) + Path=c:\windows;c:\windows\system;c:\windows\system32;w:\;w:\system;w:\system32; + ; Using this trick we have in fact two windows installations in one, we + ; get the stuff from the readonly installation and can write to our own. + Temp=t:\ (the TEMP directory) +- [Tweak.Layout] + WineLook=win95 (just the coolest look ;) +- Possibly modify the [spooler], [serialports] and [parallelports] sections. +(FIXME: possibly more, including printer stuff) + +Add this prepared configuration file to the package. + +2.3 Installing WINE for the system administrator + +Install the package using the usual packager "rpm -i wine.rpm". +You may edit /etc/wine/wine.conf, [Drive W], to point to a possible windows +installation right after the install. Thats it. + +2.4 Installing WINE for the user + +The user will need to run a setup script before the first invocation of +WINE. This script should: +- Copy /etc/wine/wine.conf for user modification. +- Allow specification of the original windows installation to use (which + modifies the copied wine.conf file). +- Create the windows directory structure (c:\windows,c:\windows\system, + c:\Program Files,c:\Desktop,etc...) + + (FIXME: Not sure this is needed for all files:) +- Symlink all .dll and .exe files from the original windows installation to + the windows directory. Why? Some program reference "%windowsdir%/file.dll" + or "%systemdir%/file.dll" directly and fail if there are not present. + This will give a huge number of symlinks, yes. However, if an installer + later overwrites on of those files, it will overwrite the symlink (so + that the file now lies in the windows/ subdirectory). + +- On later invocation the script might want to compare regular files in + the users windows directories and in the global windows directories and + replace same files by symlinks (to avoid diskspace problems). + +Done. + +This procedure requires: +- Much thought and work from the packager (1x) +- No work for the sysadmin. Well except one "rpm -i" and possible one edit + of the configuration file. +- Some or no work from the user, except running the per-user setup script + once. +=> It scales well and suffices most of the rationales. + + Marcus Meissner +