documentation/distributors - wine - Git at Google

 		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 <marcus@jet.franken.de>
	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 <marcus@jet.franken.de>