Transform the Packaging Guide into a nice ASCII file.

Update it to the latest info, make it less prone to obsolescence.
Updated the Wine executables from list produced by Tom Wickline.

documentation/.cvsignore

@@ -12,7 +12,6 @@ wine-devel
 wine-doc
 wine-doc.rtf
 wine-faq
-wine-pkg
 wine-user
 wine.man
 winelib-user

documentation/Makefile.in

@@ -51,9 +51,6 @@ WINELIB_USER_SRCS = \
 	winelib-porting.sgml \
 	winelib-toolkit.sgml
 
-WINE_PKG_SRCS = \
-	packaging.sgml
-
 WINE_FAQ_SRCS = \
 	faq.sgml
 
@@ -61,7 +58,6 @@ WINE_DOC_SRCS = \
 	$(WINELIB_USER_SRCS) \
 	$(WINE_DEVEL_SRCS) \
 	$(WINE_FAQ_SRCS) \
-	$(WINE_PKG_SRCS) \
 	$(WINE_USER_SRCS)
 
 MAN_TARGETS = wine.man
@@ -69,7 +65,6 @@ MAN_TARGETS = wine.man
 ALLBOOKS = \
 	wine-devel \
 	wine-faq \
-	wine-pkg \
 	wine-user \
 	winelib-user
 
@@ -106,7 +101,6 @@ wine-doc: wine-doc/index.html wine-doc.pdf wine-doc.ps
 
 wine-devel.pdf wine-devel.ps wine-devel/index.html: $(WINE_DEVEL_SRCS)
 wine-faq.pdf wine-faq.ps wine-faq/index.html: $(WINE_FAQ_SRCS)
-wine-pkg.pdf wine-pkg.ps wine-pkg/index.html: $(WINE_PKG_SRCS)
 wine-user.pdf wine-user.ps wine-user/index.html: $(WINE_USER_SRCS)
 winelib-user.pdf winelib-user.ps winelib-user/index.html: $(WINELIB_USER_SRCS)
 wine-doc.pdf wine-doc.ps wine-doc/index.html: $(WINE_DOC_SRCS)

documentation/PACKAGING

@@ -0,0 +1,557 @@
+INTRODUCTION
+~~~~~~~~~~~~
+
+This document attempts to establish guidelines for people making binary 
+packages of Wine.
+
+It expresses the basic principles that the Wine developers have agreed 
+should be used when building Wine. It also attempts to highlight the areas
+where there are different approaches to packaging Wine, so that the packager
+can understand the different alternatives that have been considered and their 
+rationales.
+
+TERMS
+~~~~~
+
+There are several terms and paths used in this document as place holders 
+for configurable values. Those terms are described here.
+    * WINEPREFIX: is the user's Wine configuration directory.
+	This is almost always ~/.wine, but can be overridden by
+        the user by setting the WINEPREFIX environment variable.
+
+    * PREFIX: is the prefix used when selecting an installation target.
+	The current default is /usr/local. This results in binary 
+	installation into /usr/local/bin,  library installation into 
+	/usr/local/wine/lib, and so forth.
+        This value can be overridden by the packager. In fact, FHS 2.2
+	(http://www.pathname.com/fhs/) specifications suggest that a better
+        prefix is /opt/wine.  Ideally, a packager would also allow the 
+	installer to override this value.
+
+    * ETCDIR: is the prefix that Wine uses to find the global 
+	configuration directory. This can be changed by the configure 
+	option sysconfdir.  The current default is $PREFIX/etc.
+
+    * WINDOWSDIR: is an important concept to Wine.  This directory specifies
+	what directory corresponds to the root Windows directory
+        (e.g. C:\WINDOWS). This directory is specified by the user, in
+        the user's configuration file.  Generally speaking, this directory 
+	is either set to point at an empty directory, or it is set to point 
+	at a Windows partition that has been mounted through the vfat driver.
+        NOTE:   It is extremely important that the packager understand the 
+		importance of WINDOWSDIR and convey this information and 
+		choice to the end user.
+
+GOALS
+~~~~~
+
+An installation from a Wine package should:
+    * Install quickly and simply:
+	The initial installation should require no user input.  An 
+		'rpm -i wine.rpm' or 'apt-get install wine'
+        should suffice for initial installation.
+                
+    * Work quickly and simply:
+        The user should be able to launch Solitaire
+        within minutes of downloading the Wine package.
+              
+    * Comply with Filesystem Hierarchy Standard
+        A Wine installation should, as much as possible, comply
+        with the FHS standard (http://www.pathname.com/fhs/).
+                
+    * Preserve flexibility
+        None of the flexibility built into Wine should
+        be hidden from the end user.
+
+    * Easy configuration
+        Come as preconfigured as possible, so the user does
+        not need to change any configuration files.
+
+    * Small footprint
+        Use only as much diskspace as needed per user.
+
+    * Reduce support requirements.
+        A packaged version of Wine should be sufficiently easy to use and
+	have quick and easy access to FAQs and documentation such that 
+	requests to the newsgroup and development group go down.
+        Further, it should be easy for users to capture good bug reports.
+
+REQUIREMENTS
+~~~~~~~~~~~~
+
+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 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.
+
+    * 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.
+        The current Wine standard is to use the regedit tool against 
+	the 'winedefault.reg' file to generate a default registry.
+        The current preferred method of configuring/installing
+        Wine is to run /toos/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.
+
+WINE COMPONENTS
+~~~~~~~~~~~~~~~
+
+   * Executable Files
+	- notepad : The windows Notepad replacement.
+	- progman : A Program Manager replacement.
+	- regedit : A command-line tool to edit your registry or for 
+		important a windows registry to Wine.
+	- regsvr32 : A program to register/unregister .DLL's and .OCX files. 
+		Only works on those dlls that can self-register.
+	- uninstaller: A program to uninstall installed Windows programs. 
+		Like the Add/Remove Program in the windows control panel.
+	- wcmd :  Wine's command line interpreter, a cmd.exe replacement.
+	- widl : Wine IDL compiler compiles (MS-RPC and DCOM) Interface 
+		Definition Language files.
+	- wine :  The main Wine executable. This program will load a Windows 
+		binary and run it, relying upon the Wine shared object libraries.
+	- wineboot : This program is executed on startup of the first wine 
+		process of a particular user.wineboot won't automatically run 
+		when needed.  Currently you have to manually run it after you 
+		install something.
+	- winebuild : Winebuild is a tool used for building Winelib applications 
+		(and by Wine itself) to allow a developer to compile a .spec file 
+		into a .spec.c file.
+	- wineclipserv : The Wine Clipboard Server is a standalone XLib application
+		whose purpose is to manage the X selection when Wine exits.
+	- wineconsole : Render the output of CUI programs.
+	- winedbg : A application making use of the debugging API to allow 
+		debugging of Wine or Winelib applications as well as Wine itself 
+		(kernel and all DLLs).
+	- winedump : Dumps the imports and exports of NE and PE files.
+	- winefile : A clone of the win3x filemanager.
+	- winegcc/wineg++: Wrappers for gcc/g++ respectively, to make them behave 
+		as MinGW's gcc. Used for porting apps over to Winelib.
+	- winemaker : Winemaker is a perl script which is designed to help you 
+		bootstrap the conversion of your Windows projects to Winelib. 
+	- winemine :  A clone of "Windows Minesweeper" a demo WineLib app.
+	- winepath :  A tool for converting between Windows paths and Unix paths 
+	- wineserver : The Wine server is the process that manages resources, 
+		coordinates threads, and provides synchronization and interprocess 
+		communication primitives to Wine processes.
+	- wineshelllink : This shell script can be called by Wine in order to 
+		propagate Desktop icon and menu creation requests out to a 
+		GNOME or KDE (or other Window Managers).
+	- winewrap : Takes care of linking winelib applications. Linking with 
+		Winelib is a complex process, winewrap makes it simple.
+	- winhelp : A Windows Help replacement.
+	- wmc : Wine Message Compiler it allows Windows message files to be 
+		compiled into a format usable by Wine.
+	- wrc : the Wine Resource Compiler. A clone of Microsoft's rc.
+
+    * Shared Object Library Files
+	To obtain a current list of DLLs, run:
+		ls dlls/*.so
+	it the root of the Wine _build_ tree, after a sucessful build.
+
+    * Man Pages
+	To obtain a current list of man files that need to be installed, run:
+		find . -name "*.man"
+	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.
+
+    * Documentation files
+	After building the documentation with:
+		cd documentation; make html
+	install all the files from: wine-user/, wine-devel/ and winelib-user/.
+
+     * Dynamic Wine Files
+        Wine also generates and depends on a number of dynamic
+        files, including user configuration files and registry files.
+
+        At the time of this writing, there was not a clear
+        consensus of where these files should be located, and how
+        they should be handled.  This section attempts
+        to explain the alternatives clearly.
+
+        - WINEPREFIX/config
+            This file is the user local Wine configuration file.
+            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.
+
+    * Registry Files
+            In order to replicate the Windows registry system,
+            Wine stores registry entries in a series of files.
+
+            For an excellent overview of this issue, read this
+            http://www.winehq.com/News/2000-25.html#FTR
+            Wine Weekly News feature.
+
+            The bottom line is that, at Wine server startup,
+            Wine loads all registry entries into memory
+            to create an in memory image of the registry.
+            The order of files which Wine uses to load
+            registry entries is extremely important,
+            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,
+            the local registry files take precedence.
+
+            Then, at exit (or at periodic intervals),
+            Wine will write either all registry entries
+            (or, with the default setting) changed
+            registry entries to files in the WINEPREFIX.
+
+	    - WINEPREFIX/system.reg
+                This file contains the user's local copy of the 
+		HKEY_LOCAL_MACHINE registry hive.  In general use, it will
+		contain only changes made to the default registry values.
+
+	    - WINEPREFIX/user.reg
+                This file contains the user's local copy of the 
+		HKEY_CURRENT_MACHINE registry hive.  In general use, it will
+		contain only changes made to the default registry values.
+
+	    - WINEPREFIX/userdef.reg
+                This file contains the user's local copy of the 
+		HKEY_USERS\.Default registry hive.  In general use, it will
+		contain only changes made to the default registry values.
+
+	    - WINEPREFIX/cachedmetrics.[display]
+                This file contains font metrics for the given X display.
+                Generally, this cache is generated once at Wine start time.
+                cachedmetrics can be generated if absent. 
+		You should note this can take a long time.
+
+	    - ETCDIR/wine.systemreg 
+                This file contains the global values for HKEY_LOCAL_MACHINE. 
+		The values in this file can be overridden by the user's 
+		local settings. The location of this directory is hardcoded 
+		within wine, generally to /etc. 
+
+	    - ETCDIR/wine.userreg
+                This file contains the global values for HKEY_USERS.  
+		The values in this file can be overridden by the user's 
+		local settings.  This file is likely to be deprecated in
+                favor of a global wine.userdef.reg that will only contain 
+		HKEY_USERS/.Default.
+
+    * Important Files from a Windows Partition
+        Wine has the ability to use files from an installation of the
+        actual Microsoft Windows operating system.  Generally these
+        files are loaded on a VFAT partition that is mounted under Linux.
+
+        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 
+	distinction clear to the end user, so that they can intelligently
+        choose their configuration.
+
+        - WINDOWSDIR/system32/system.dat
+        - WINDOWSDIR/system32/user.dat
+	- WINDOWSDIR/win.ini
+
+    * Windows Dynamic Link Libraries (WINDOWSDIR/system32/*.dll)
+        Wine has the ability to use the actual Windows DLL files
+        when running an application.  An end user can configure
+        Wine so that Wine uses some or all of these DLL files
+        when running a given application.
+
+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 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 
+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?
+        At this point, common practice is to adopt to the conventions
+	of the targeted distribution. 
+
+    * Where to install files
+        This question is not really contested.  It will vary
+        by distribution, and is really up to the packager.
+        As a guideline, the current 'make install' process
+        seems to behave such that if we pick a single PREFIX then:
+            - binary files go into PREFIX/bin
+	    - library files go into PREFIX/lib/wine
+	    - include files go into PREFIX/include/wine
+	    - man pages go into PREFIX/share/man
+	    - documentation files go into PREFIX/share/doc/wine-VERSION
+
+	You might also want to use the wine wrapper script winelauncher
+	that can be found in tools/ directory, as it has several important
+	advantages over directly invoking the wine binary.
+	See the Executable Files section for details.
+
+    * The question of /opt/wine
+        The FHS 2.2 specification suggests that Wine as a package
+        should be installed to /opt/wine.  None of the existing packages 
+	follow this guideline (today; check again tomorrow).
+
+    * 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.
+
+IMPLEMENTATION
+~~~~~~~~~~~~~~
+
+This section discusses the implementation of a Red Hat 8.0 .spec file.
+For a current .spec file, please refer to any one of the existing SRPMs.
+
+1. Building the package
+
+Wine is configured the usual way (depending on your build environment). 
+The PREFIX is chosen using your application placement policy
+(/usr/, /usr/X11R6/, /opt/wine/, or similar).  The configuration files
+(wine.conf, wine.userreg, wine.systemreg) are targeted for /etc/wine/
+(rationale: FHS 2.2, 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
+	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 seperate 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 clipboard server is started on demand.
+	install -m 755 dlls/x11drv/wineclipsrv $BR/usr/X11R6/bin/
+
+	# The Wine server is needed.
+	install -m 755 server/wineserver $BR/usr/X11R6/bin/
+
+Here we unfortunately do need to create wineuser.reg and winesystem.reg
+from the Wine distributed winedefault.reg. This can be done using regedit
+once for one example user and then reusing his WINEPREFIX/user.reg and
+WINEPREFIX/system.reg files.
+FIXME: this needs to be done better.
+
+	install -m 644 wine.sytemreg $BR/etc/wine/
+	install -m 644 wine.userreg $BR/etc/wine/
+
+There are now a lot of libraries generated by the build process, so a 
+seperate 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/bin/dosmod, $prefix/lib/wine/*
+	$prefix/man/man1/wine.1, $prefix/include/wine/*,
+	$prefix/bin/wineserver, $prefix/bin/wineclipsrv
+
+	%config /etc/wine/*
+	%doc ... choose from the toplevel directory and documentation/
+
+The post-install script:
+
+	if ! grep -q /usr/X11R6/lib/wine /etc/ld.so.conf; 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.
+		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)
+
+    * [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.
+
+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.
+
+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,
+as several stupid Windows programs mark some setup (!) files as hidden 
+(ISO9660) on CD-ROMs, which will greatly confuse users as they won't find 
+their setup files on the CD-ROMs as they were used on Windows systems when
+unhide is not set ;-\ And of course the setup program will complain
+that setup.ins or some other mess is missing... If you choose to do so, 
+then please make this change verbose to the admin.
+
+Also make sure that the kernel you use includes the Joliet CD-ROM support, 
+for the very same reasons as given above (no long filenames due to missing 
+Joliet, files not found).
+              
+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).
+    
+AUTHORS
+~~~~~~~
+
+Written in 1999 by Marcus Meissner <marcus@jet.franken.de>
+Updated in 2000 by Jeremy White <jwhite@codeweavers.com>
+Updated in 2002 by Andreas Mohr <andi@rhlx01.fht-esslingen.de>
+Updated in 2003 by Tom Wickline <twickline2@triad.rr.com>
+Updated in 2003 by Dimitrie O. Paun <dpaun@rogers.com>

documentation/make_winehq

@@ -33,11 +33,9 @@ echo "./db2html-winehq wine-devel.sgml"
 ./db2html-winehq wine-devel.sgml
 echo "./db2html-winehq winelib-user.sgml"
 ./db2html-winehq winelib-user.sgml
-echo "./db2html-winehq wine-pkg.sgml"
-./db2html-winehq wine-pkg.sgml
 echo "./db2html-winehq wine-faq.sgml"
 ./db2html-winehq wine-faq.sgml
-tar czf winedoc-html.tgz wine-user wine-devel winelib-user wine-pkg wine-faq
+tar czf winedoc-html.tgz wine-user wine-devel winelib-user wine-faq
 cp winedoc-html.tgz "$WWWDIR"
 
 ## Create one-book HTML tarball
@@ -53,11 +51,9 @@ echo "db2ps -d ./print.dsl wine-devel.sgml"
 db2ps -d ./print.dsl wine-devel.sgml > /dev/null 2>&1
 echo "db2ps -d ./print.dsl winelib-user.sgml"
 db2ps -d ./print.dsl winelib-user.sgml > /dev/null 2>&1
-echo "db2ps -d ./print.dsl wine-pkg.sgml"
-db2ps -d ./print.dsl wine-pkg.sgml > /dev/null 2>&1
 echo "db2ps -d ./print.dsl wine-faq.sgml"
 db2ps -d ./print.dsl wine-faq.sgml > /dev/null 2>&1
-tar czf winedoc-ps.tgz wine-user.ps wine-devel.ps winelib-user.ps wine-pkg.ps wine-faq.ps
+tar czf winedoc-ps.tgz wine-user.ps wine-devel.ps winelib-user.ps wine-faq.ps
 cp winedoc-ps.tgz "$WWWDIR"
 
 ## Create PDF tarball
@@ -67,11 +63,9 @@ echo "db2pdf -d ./print.dsl wine-devel.sgml"
 db2pdf -d ./print.dsl wine-devel.sgml > /dev/null 2>&1
 echo "db2pdf -d ./print.dsl winelib-user.sgml"
 db2pdf -d ./print.dsl winelib-user.sgml > /dev/null 2>&1
-echo "db2pdf -d ./print.dsl wine-pkg.sgml"
-db2pdf -d ./print.dsl wine-pkg.sgml > /dev/null 2>&1
 echo "db2pdf -d ./print.dsl wine-faq.sgml"
 db2pdf -d ./print.dsl wine-faq.sgml > /dev/null 2>&1
-tar czf winedoc-pdf.tgz wine-user.pdf wine-devel.pdf winelib-user.pdf wine-pkg.pdf wine-faq.pdf
+tar czf winedoc-pdf.tgz wine-user.pdf wine-devel.pdf winelib-user.pdf wine-faq.pdf
 cp winedoc-pdf.tgz "$WWWDIR"
 
 ## Create SGML tarball
@@ -94,9 +88,7 @@ echo "./db2html-winehq wine-devel.sgml"
 ./db2html-winehq wine-devel.sgml
 echo "./db2html-winehq winelib-user.sgml"
 ./db2html-winehq winelib-user.sgml
-echo "./db2html-winehq wine-pkg.sgml"
-./db2html-winehq wine-pkg.sgml
 echo "./db2html-winehq wine-faq.sgml"
 ./db2html-winehq wine-faq.sgml
-tar czf winehq-shtml.tgz wine-user wine-devel winelib-user wine-pkg wine-faq
+tar czf winehq-shtml.tgz wine-user wine-devel winelib-user wine-faq
 cp winehq-shtml.tgz "$WWWDIR"

documentation/wine-doc.sgml

@@ -45,9 +45,6 @@
 <!entity winelib-bindlls SYSTEM "winelib-bindlls.sgml">
 <!entity winelib-packaging SYSTEM "winelib-pkg.sgml">
 
-<!-- *** Entities for Wine Packagers Guide *** -->
-<!entity packaging SYSTEM "packaging.sgml">
-
 <!-- *** Entities for Wine FAQ *** -->
 <!entity faq SYSTEM "faq.sgml">
 
@@ -141,14 +138,6 @@
 
   </book>
 
-  <!-- *** Wine Packager Guide *** -->
-  <book id="index-pkg">
-    <bookinfo>
-      <title>Wine Packagers Guide</title>
-    </bookinfo>
-
-    &packaging;
-
   </book>
   <!-- *** Wine Faq *** -->
   <book id="faq">

documentation/wine-pkg.sgml

@@ -1,17 +0,0 @@
-<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
-
-<!-- *** Include list of authors *** -->
-<!entity % authors SYSTEM "authors.ent">
-%authors;
-
-<!entity packaging SYSTEM "packaging.sgml">
-]>
-
-<book id="index">
-  <bookinfo>
-    <title>Wine Packagers Guide</title>
-  </bookinfo>
-
-  &packaging;
-
-</book>