PATCH: PACKAGERS

Marcus Meissner meissner at suse.de
Fri Nov 26 09:18:49 CST 2004


Hi,

Updated PACKAGING howto.

Ciao, Marcus

Changelog:
	Updated PACKAGING howto to current time.

Index: documentation/PACKAGING
===================================================================
RCS file: /home/wine/wine/documentation/PACKAGING,v
retrieving revision 1.11
diff -u -r1.11 PACKAGING
--- documentation/PACKAGING	27 Sep 2004 20:28:56 -0000	1.11
+++ documentation/PACKAGING	26 Nov 2004 16:15:53 -0000
@@ -68,6 +68,10 @@
       better support of fonts than using the X11 fonts engine. It is 
       only needed for the X11 back end engine. Used from GDI.
 
+    * fontconfig
+      Used to find TrueType fonts for rendering with freetype. Used by
+      GDI.
+
     * Alsa: http://sourceforge.net/projects/alsa (Linux only)
       This library gives sound support to the Windows environment.
 
@@ -75,7 +79,8 @@
       Similar to Alsa, it allow Wine to use the JACK audio server.
 
     * CUPS: http://www.cups.org
-      This library allows Windows to see CUPS defined printers.
+      This library allows Windows to see CUPS defined printers. Used
+      by WINEPS and WINSPOOL.
 
     * OpenGL
       This is used for both OpenGL and Direct3D (and some other 
@@ -90,6 +95,30 @@
     * LittleCMS: http://www.littlecms.com
       This library is used to implement MSCMS (Color Management System)
       which is needed by an increasing number of graphics applications.
+    
+    * libjpeg
+      This library is used to load JPEG files within OLE automation.
+
+    * libungif or gif_lib
+      One of these two libraries is used to load GIF files within OLE
+      automation.
+
+    * ICU and fribidi
+      Used for bidirectional character output. Linked statically, used
+      by GDI.
+
+    * sane
+      Used for basic scanner support in our TWAIN32 library.
+
+    * openssl
+      Used for some cryptographic support in ADVAPI32.
+ 
+    * Xrandr, Xrender, Xi, Xext
+      X11 extension libraries used by the x11drv.
+      Xrandr - resolution switching
+      Xrender - client side font rendering
+      Xi - X Input handling (for asian input methods mostly)
+      Xext - X extensions
 
 GOALS
 ~~~~~
@@ -101,8 +130,8 @@
         should suffice for initial installation.
                 
     * Work quickly and simply:
-        The user should be able to launch Solitaire
-        within minutes of downloading the Wine package.
+        The user should be able to launch Solitaire within seconds
+	of downloading the Wine package.
               
     * Comply with Filesystem Hierarchy Standard
         A Wine installation should, as much as possible, comply
@@ -129,32 +158,31 @@
 ~~~~~~~~~~~~
 
 Successfully installing Wine requires:
-    * Much thought and work from the packager (1x)
 
-    * A configuration file
-        Wine will not run without a configuration file.  Wine provides a
-        a sample config file and it can be found in documentation/samples.
+    * Some thought and work from the packager
+
+    * No longer: A configuration file
+        Wine will run without a configuration file at this time.  Wine
+	provides a a sample config file and it can be found in
+	documentation/samples.
+
         Some packagers may attempt to provide (or dynamically generate) a 
-	default configuration file. Some packagers may wish to rely on 
-	winesetup to generate the configuration file.
+	default configuration file. Some packagers may copy this on
+	startup, but it is no longer necessary.
+
+    * Running wineprefixcreate in a fake windows setup.
 
-    * A writeable C drive
-        A writeable C:\ directory structure on a per-user basis. 
-	Applications do dump .ini file into C:\WINDOWS, installer
-	dump .exe/.dll/etc. files into C:\WINDOWS or C:\Program Files.
-
-    * An initial set of registry entries.
-	For custom changes to the default registry, tools/wine.inf
-	can be modified as needed. The current preferred method of 
-	configuring/installing Wine is to run /tools/wineinstall.  
-	There are several other choices that could be made; registries 
-	can be imported from a Windows partition.  At this time, Wine 
-	does not completely support a complex multi-user installation 
-	ala Windows NT, but it could fairly readily.
-
-     * Special files
-        Some special .dll and .exe files in the C:\WINDOWS\SYSTEM
-	directory, since applications directly check for their presence.
+        This will load all default registry entries, and register dlls
+	where necessary. A special "wine.inf" file is provided with
+	the WINE sources and installed to /usr/share/wine/.
+
+	Currently wine itself has no hook to run this per default
+	on a not-yet setup fake windows setup.
+
+	A packager should either call wineprefixcreate on 
+	the first startup automatically (via a wrapper scripts
+	around wine) or make this option easily available to 
+	the user.
 
 WINE COMPONENTS
 ~~~~~~~~~~~~~~~
@@ -218,7 +246,8 @@
 	it the root of the Wine _build_ tree, after you have run ./configure.
 
     * Include Files
-	An up to date list of includes can be found in the include/Makefile.in file.
+	An up to date list of includes can be found in the include/Makefile.in
+	file.
 
     * Documentation files
 	After building the documentation with:
@@ -239,22 +268,10 @@
             At the time of this writing, if this file exists,
             then no other configuration file is loaded.
 
-        - ETCDIR/wine.conf
-            This is the global Wine configuration file. It is only used
-	    if the user running Wine has no local configuration file.
-	    Global wine configuration is currently not possible;
-	    this might get reenabled at some time.
-            Some packagers feel that this file should not be supplied, 
-	    and that only a wine.conf.default should be given here.
-            Other packagers feel that this file should be the predominant
-	    file used, and that users should only shift to a local 
-	    configuration file if they need to.  An argument has been
-            made that the local configuration file should inherit the 
-	    global configuration file.  At this time, Wine does not do this;
-            please refer to the WineHQ discussion archives for the debate 
-	    concerning this.
-            This debate is addressed more completely below, in the
-	    'Packaging Strategy' section.
+        - PREFIX/share/wine.inf
+	
+            This is the global Wine setup information file
+	    in the format of a MS Installer .INF file.
 
     * Registry Files
             In order to replicate the Windows registry system,
@@ -272,7 +289,6 @@
             as it affects what registry entries are
             actually present.  The order is roughly that
             .dat files from a Windows partion are loaded,
-            then global registry settings from ETCDIR,
             and then finally local registry settings are
             loaded from WINEPREFIX.  As each set are loaded,
             they can override the prior entries.  Thus,
@@ -324,7 +340,7 @@
 
         This is probably the most important configuration detail.
         The use of Windows registry and DLL files dramatically alters the 
-	behaviour of Wine. If nothing else, pacakager have to make this 
+	behaviour of Wine. If nothing else, packager have to make this 
 	distinction clear to the end user, so that they can intelligently
         choose their configuration.
 
@@ -341,22 +357,26 @@
 PACKAGING STRATEGIES
 ~~~~~~~~~~~~~~~~~~~~
 
-There has recently been a lot of discussion on the Wine
-development mailing list about the best way to build Wine packages.
+There has recently been a lot of discussion on the Wine development
+mailing list about the best way to build Wine packages.
 
 There was a lot of discussion, and several diverging points of view.
-This section of the document attempts to present the areas of common 
-agreement, and also to present the different approaches advocated on 
+This section of the document attempts to present the areas of common
+agreement, and also to present the different approaches advocated on
 the mailing list.
 
     * Distribution of Wine into packages
         The most basic question to ask is given the Wine CVS tree,
         what physical files are you, the packager, going to produce?
-        Are you going to produce only a wine.rpm (as Marcus has done),
-        or are you going to produce 6 Debian files (libwine, libwine-dev,
-	wine, wine-doc, wine-utils and winesetuptk) as Ove has done?
+        Are you going to produce only a wine.rpm, or are you going to
+	produce 6 Debian files (libwine, libwine-dev, wine, wine-doc,
+	wine-utils and winesetuptk) as Ove has done?
         At this point, common practice is to adopt to the conventions
-	of the targeted distribution. 
+	of the targeted distribution.
+
+	Also, experience shows that you should not create a huge set
+	of packages, since later upgrades and obsoletion will be
+	painful.
 
     * Where to install files
         This question is not really contested.  It will vary
@@ -379,62 +399,32 @@
         should be installed to /opt/wine.  None of the existing packages 
 	follow this guideline (today; check again tomorrow).
 
+	(Since most are upgrades of the distro packages, this is still
+	 on the safe side I think - Marcus Meissner)
+
     * What files to create
         After installing the static and shareable files, the next
         question the packager needs to ask is how much dynamic
         configuration will be done, and what configuration
         files should be created.
-        There are several approaches to this:
-            - Rely completely on user file space - install nothing
-                This approach relies upon the new winesetup utility
-                and the new ability of Wine to launch winesetup if no
-                configuration file is found.  The basic concept is
-                that no global configuration files are created at
-                install time.  Instead, Wine configuration files are
-                created on the fly by the winesetup program when Wine
-                is invoked.  Further, winesetup creates default
-                Windows directories and paths that are stored
-                completely in the user's WINEPREFIX.  This approach
-                has the benefit of simplicity in that all Wine files
-                are either stored under /opt/wine or under ~/.wine.
-                Further, there is only ever one Wine configuration
-                file.  This approach, however, adds another level of
-                complexity.  It does not allow Wine to run Solitaire
-                'out of the box'; the user must run the configuration
-                program first.  Further, winesetup requires Tcl/Tk, a
-                requirement not beloved by some.  Additionally, this
-                approach closes the door on multi user configurations
-                and presumes a single user approach.
-
-	    - Build a reasonable set of defaults for the global wine.conf,
-	      facilitate creation of a user's local Wine configuration.
-                This approach, best shown by Marcus, causes the
-                installation process to auto scan the system,
-                and generate a global wine.conf file with best
-                guess defaults.  The OpenLinux packages follow
-                this behaviour.
-                The keys to this approach are always putting
-                an existing Windows partition into the
-                path, and being able to run Solitaire
-                right out of the box.
-                Another good thing that Marcus does is he
-                detects a first time installation and
-                does some clever things to improve the
-                user's Wine experience.
-                A flaw with this approach, however, is it doesn't
-                give the user an obvious way to choose not to
-                use a Windows partition.
-
-	    - Build a reasonable set of defaults for the global wine.conf,
-              and ask the user if possible
-                This approach, demonstrated by Ove, causes the
-                installation process to auto scan the system,
-                and generate a global wine.conf file with best
-                guess defaults.  Because Ove built a Debian
-                package, he was able to further query debconf and
-                get permission to ask the user some questions,
-                allowing the user to decide whether or not to
-                use a Windows partition.
+
+        The best current approach to this is:
+	- Leave it alone and make a "wineprefixcreate" call available
+	  to the user via a menu item or similar.
+
+        - Setup a fake windows setup automatically.
+		
+		This is done by simply calling wineprefixcreate, 
+		which will setup a fake windows root for the user.
+
+		If no arguments are passed, defaults will be 
+		assumed for WINEPREFIX (~/.wine) and similar
+		variables.
+
+		After this, WINE is immediately useable by the
+		end user.
+
+	- Others might be possible.
 
 IMPLEMENTATION
 ~~~~~~~~~~~~~~
@@ -453,101 +443,42 @@
 Example (split this into %build and %install section for rpm:
 
 
-	CFLAGS=$RPM_OPT_FLAGS ./configure --prefix=/usr/X11R6 --sysconfdir=/etc/wine/ --enable-dll
+	CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=/usr/X11R6 --sysconfdir=/etc/wine/ --enable-dll
 	make
 	BR=$RPM_BUILD_ROOT
 	make install prefix=$BR/usr/X11R6/ sysconfdir=$BR/etc/wine/
-	install -d $BR/etc/wine/
-	install -m 644 wine.ini $BR/etc/wine/wine.conf
-
-	# Put all our DLLs in a separate directory. (this works only if you have a buildroot)
-	install -d $BR/usr/X11R6/lib/wine
-	mv $BR/usr/X11R6/lib/lib* $BR/usr/X11R6/lib/wine/
 
-	# The Wine server is needed.
-	install -m 755 server/wineserver $BR/usr/X11R6/bin/
-
-
-There are now a lot of libraries generated by the build process, so a 
-separate library directory should be used.
-
-	install -d 755 $BR/usr/X11R6/lib/
-	mv $BR/
-        
 You will need to package the files:
 
-	$prefix/bin/wine, $prefix/lib/wine/*
+	$prefix/bin/wine*
+	$prefix/lib/wine/*, $prefix/libwine*
 	$prefix/man/man1/wine.1, $prefix/include/wine/*,
-	$prefix/bin/wineserver
+	$prefix/share/wine/wine.inf
+
+	$prefix/bin/notepad
+	$prefix/bin/progman
+	$prefix/bin/regedit
+	$prefix/bin/rundll32
+	$prefix/bin/regsvr32
+	$prefix/bin/wcmd
+	$prefix/bin/widl
+	$prefix/bin/winhelp
 
 	%config /etc/wine/*
 	%doc ... choose from the toplevel directory and documentation/
 
-The post-install script:
-
-	if ! grep /usr/X11R6/lib/wine /etc/ld.so.conf >/dev/null; then
-	    echo "/usr/X11R6/lib/wine" >> /etc/ld.so.conf
-	fi
-	/sbin/ldconfig
-
-The post-uninstall script:
-
-	if [ "$1" = 0 ]; then
-	    perl -ni -e 'print unless m:/usr/X11R6/lib/wine:;' /etc/ld.so.conf
-	fi
-	/sbin/ldconfig
-
 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 distribution's default floppy mountpoint.
-		Path=/auto/floppy
-	- C for the C:\ directory. Here we use the user's home directory, for most
-	  applications do see C:\ as root-writeable directory of every windows
-	  installation and this basically is it in the UNIX-user context.
-	  Don't forget to identify environment variables as DOS ones (ie, surrounded by '%').
-		Path=%HOME%
-	- R for the CD-Rom drive. Specify your distribution's default CD-ROM mountpoint.
-		Path=/auto/cdrom
-	- T for temporary storage. We do use /tmp/ (rationale: between process 
-	  temporary data belongs to /tmp/ , FHS 2.0)
-		Path=/tmp/
-	- W for the original Windows installation. This drive points to the
-	  WINDOWSDIR subdirectory of the original windows installation.
-	  This avoids problems with renamed WINDOWSDIR 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. This avoids any roblems with 
-	  "could not find drive for current directory" users occasionally complain
-	  about in the newsgroup and the irc channel. It also makes the whole 
-	  directory structure browseable. The type of Z should be network,
-	  so applications expect it to be readonly.
-		Path=/
-	  
-    * [wine]:
-	Windows=c:\windows\ 		(the windows/ subdirectory in the user's
-				 home directory)
-	System=c:\windows\system\	(the windows/system subdirectory in the user's
-  					 home directory)
-	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)
+This is no longer necessary, most of this work is now done
+by wineprefixcreate itself
 
-    * Possibly modify the [spooler], [serialports] and [parallelports] sections.
-      FIXME: possibly more, including printer stuff.
-
-Add this prepared configuration file to the package.
 
 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. That's it.
+
+Adapting the $prefix/share/wine/wine.inf file used by wineprefixcreate is not
+necessary.
 
 Note that on Linux you should somehow try to add the unhide mount optioni
 (see 'man mount') to the CD-ROM entry in /etc/fstab during package install,
@@ -564,24 +495,14 @@
               
 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:\windows\Start Menu\Programs, c:\Program Files, c:\Desktop, etc.)
-    * Symlink all .dll and .exe files from the original windows installation
-      to the windows directory. Why? Some programs reference 
-      "%windowsdir%/file.dll" or "%systemdir%/file.dll" directly and fail
-      if they are not present.  This will give a huge number of symlinks, yes.
-      However, if an installer later overwrites one of those files, it will 
-      overwrite the symlink (so that the file now lies in the windows/
-      subdirectory). FIXME: Not sure this is needed for all files.
-    * On later invocation the script might want to compare regular files in 
-      the user's windows directories and in the global windows directories
-      and replace same files by symlinks (to avoid diskspace problems).
-    
+The user will need to run a wineprefixcreate before the first invocation
+of Wine.
+
+A packager might provide a wrapper for wine to do that automatically,
+like if the WINEPREFIX directory (~/.wine) is not present.
+
+Thats it.
+
 AUTHORS
 ~~~~~~~
 
@@ -590,3 +511,4 @@
 Updated in 2002 by Andreas Mohr <andi at rhlx01.fht-esslingen.de>
 Updated in 2003 by Tom Wickline <twickline2 at triad.rr.com>
 Updated in 2003 by Dimitrie O. Paun <dpaun at rogers.com>
+Updated in 2004 by Marcus Meissner <marcus at jet.franken.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20041126/c4988cd0/attachment.pgp


More information about the wine-patches mailing list