ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated PACKAGING howto.

This commit is contained in:
Marcus Meissner 2004-11-28 15:00:03 +00:00 committed by Alexandre Julliard
parent a96a700cf2
commit 7292117fe8
1 changed files with 125 additions and 205 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

310
documentation/PACKAGING
View File

@ -50,7 +50,7 @@ There are two types of dependencies: hard and soft dependencies.
A hard dependency must be available at runtime for Wine to function, A hard dependency must be available at runtime for Wine to function,
if compiled into the code. Soft dependencies on the other hand if compiled into the code. Soft dependencies on the other hand
will degrade gracefully at runtime if unavailable on the runtime system. will degrade gracefully at runtime if unavailable on the runtime system.
Ideally, we should eliminate all hard dependencies in favour of Ideally, we should eliminate all hard dependencies in favor of
soft dependencies. soft dependencies.
To enable a soft dependency, it must be available at compile time. To enable a soft dependency, it must be available at compile time.
@ -68,6 +68,10 @@ they should appear as "Suggests" or "Recommends", as the case may be.
better support of fonts than using the X11 fonts engine. It is better support of fonts than using the X11 fonts engine. It is
only needed for the X11 back end engine. Used from GDI. 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) * Alsa: http://sourceforge.net/projects/alsa (Linux only)
This library gives sound support to the Windows environment. This library gives sound support to the Windows environment.
@ -75,7 +79,8 @@ they should appear as "Suggests" or "Recommends", as the case may be.
Similar to Alsa, it allow Wine to use the JACK audio server. Similar to Alsa, it allow Wine to use the JACK audio server.
* CUPS: http://www.cups.org * 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 * OpenGL
This is used for both OpenGL and Direct3D (and some other This is used for both OpenGL and Direct3D (and some other
@ -91,6 +96,30 @@ they should appear as "Suggests" or "Recommends", as the case may be.
This library is used to implement MSCMS (Color Management System) This library is used to implement MSCMS (Color Management System)
which is needed by an increasing number of graphics applications. 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
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 GOALS
~~~~~ ~~~~~
@ -101,8 +130,8 @@ An installation from a Wine package should:
should suffice for initial installation. should suffice for initial installation.
* Work quickly and simply: * Work quickly and simply:
The user should be able to launch Solitaire The user should be able to launch Solitaire within seconds
within minutes of downloading the Wine package. of downloading the Wine package.
* Comply with File system Hierarchy Standard * Comply with File system Hierarchy Standard
A Wine installation should, as much as possible, comply A Wine installation should, as much as possible, comply
@ -129,32 +158,27 @@ REQUIREMENTS
~~~~~~~~~~~~ ~~~~~~~~~~~~
Successfully installing Wine requires: Successfully installing Wine requires:
* Much thought and work from the packager (1x)
* A configuration file * Install the RPM.
Wine will not run without a configuration file. Wine provides a
a sample config file and it can be found in documentation/samples. * No longer: A configuration file
Wine will run without a configuration file at this time. Wine
provides a sample config file and it can be found in
documentation/samples.
Some packagers may attempt to provide (or dynamically generate) a Some packagers may attempt to provide (or dynamically generate) a
default configuration file. Some packagers may wish to rely on default configuration file. Some packagers may copy this on
winesetup to generate the configuration file. startup, but it is no longer necessary.
* A writeable C drive * No longer: Preparing a fake windows setup.
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. If WINEPREFIX is not present, wine will generate a setup
For custom changes to the default registry, tools/wine.inf by itself by calling wineprefixcreate.
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 This will load all default registry entries, and register dlls
Some special .dll and .exe files in the C:\WINDOWS\SYSTEM where necessary. A special "wine.inf" file is provided with
directory, since applications directly check for their presence. the WINE sources and installed to /usr/share/wine/.
WINE COMPONENTS WINE COMPONENTS
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
@ -218,7 +242,8 @@ WINE COMPONENTS
it the root of the Wine _build_ tree, after you have run ./configure. it the root of the Wine _build_ tree, after you have run ./configure.
* Include Files * 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 * Documentation files
After building the documentation with: After building the documentation with:
@ -239,22 +264,10 @@ WINE COMPONENTS
At the time of this writing, if this file exists, At the time of this writing, if this file exists,
then no other configuration file is loaded. then no other configuration file is loaded.
- ETCDIR/wine.conf - PREFIX/share/wine.inf
This is the global Wine configuration file. It is only used
if the user running Wine has no local configuration file. This is the global Wine setup information file
Global wine configuration is currently not possible; in the format of a MS Installer .INF file.
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 * Registry Files
In order to replicate the Windows registry system, In order to replicate the Windows registry system,
@ -271,8 +284,7 @@ WINE COMPONENTS
registry entries is extremely important, registry entries is extremely important,
as it affects what registry entries are as it affects what registry entries are
actually present. The order is roughly that actually present. The order is roughly that
.dat files from a Windows partion are loaded, .dat files from a Windows partition are loaded,
then global registry settings from ETCDIR,
and then finally local registry settings are and then finally local registry settings are
loaded from WINEPREFIX. As each set are loaded, loaded from WINEPREFIX. As each set are loaded,
they can override the prior entries. Thus, they can override the prior entries. Thus,
@ -324,7 +336,7 @@ WINE COMPONENTS
This is probably the most important configuration detail. This is probably the most important configuration detail.
The use of Windows registry and DLL files dramatically alters the The use of Windows registry and DLL files dramatically alters the
behaviour of Wine. If nothing else, pacakager have to make this behavior of Wine. If nothing else, packager have to make this
distinction clear to the end user, so that they can intelligently distinction clear to the end user, so that they can intelligently
choose their configuration. choose their configuration.
@ -341,8 +353,8 @@ WINE COMPONENTS
PACKAGING STRATEGIES PACKAGING STRATEGIES
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
There has recently been a lot of discussion on the Wine There has recently been a lot of discussion on the Wine development
development mailing list about the best way to build Wine packages. mailing list about the best way to build Wine packages.
There was a lot of discussion, and several diverging points of view. There was a lot of discussion, and several diverging points of view.
This section of the document attempts to present the areas of common This section of the document attempts to present the areas of common
@ -352,12 +364,16 @@ the mailing list.
* Distribution of Wine into packages * Distribution of Wine into packages
The most basic question to ask is given the Wine CVS tree, The most basic question to ask is given the Wine CVS tree,
what physical files are you, the packager, going to produce? what physical files are you, the packager, going to produce?
Are you going to produce only a wine.rpm (as Marcus has done), Are you going to produce only a wine.rpm, or are you going to
or are you going to produce 6 Debian files (libwine, libwine-dev, produce 6 Debian files (libwine, libwine-dev, wine, wine-doc,
wine, wine-doc, wine-utils and winesetuptk) as Ove has done? wine-utils and winesetuptk) as Ove has done?
At this point, common practice is to adopt to the conventions 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 obsoleting will be
painful.
* Where to install files * Where to install files
This question is not really contested. It will vary This question is not really contested. It will vary
by distribution, and is really up to the packager. by distribution, and is really up to the packager.
@ -379,62 +395,32 @@ the mailing list.
should be installed to /opt/wine. None of the existing packages should be installed to /opt/wine. None of the existing packages
follow this guideline (today; check again tomorrow). 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 * What files to create
After installing the static and shareable files, the next After installing the static and shareable files, the next
question the packager needs to ask is how much dynamic question the packager needs to ask is how much dynamic
configuration will be done, and what configuration configuration will be done, and what configuration
files should be created. 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, The best current approach to this is:
facilitate creation of a user's local Wine configuration. - Leave it alone and make a "wineprefixcreate" call available
This approach, best shown by Marcus, causes the to the user via a menu item or similar.
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, - Setup a fake windows setup automatically.
and ask the user if possible
This approach, demonstrated by Ove, causes the This is done by simply calling wineprefixcreate,
installation process to auto scan the system, which will setup a fake windows root for the user.
and generate a global wine.conf file with best
guess defaults. Because Ove built a Debian If no arguments are passed, defaults will be
package, he was able to further query debconf and assumed for WINEPREFIX (~/.wine) and similar
get permission to ask the user some questions, variables.
allowing the user to decide whether or not to
use a Windows partition. After this, WINE is immediately usable by the
end user.
- Others might be possible.
IMPLEMENTATION IMPLEMENTATION
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
@ -453,103 +439,46 @@ The PREFIX is chosen using your application placement policy
Example (split this into %build and %install section for rpm: 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 make
BR=$RPM_BUILD_ROOT BR=$RPM_BUILD_ROOT
make install prefix=$BR/usr/X11R6/ sysconfdir=$BR/etc/wine/ 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: You will need to package the files:
$prefix/bin/wine, $prefix/lib/wine/* $prefix/bin/wine*
$prefix/man/man1/wine.1, $prefix/include/wine/*, $prefix/lib/libwine*
$prefix/bin/wineserver $prefix/lib/wine/*,
$prefix/share/wine/wine.inf
$prefix/man/man1/wine.1
$prefix/include/wine/*
$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/* %config /etc/wine/*
%doc ... choose from the top level directory and documentation/ %doc ... choose from the top level 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. 2. Creating a good default configuration file.
For the rationales of needing as less input from the user as possible arises This is no longer necessary, most of this work is now done
the need for a very good configuration file. The one supplied with Wine is by wineprefixcreate itself
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)
* 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 3. Installing Wine for the system administrator
Install the package using the usual packager 'rpm -i wine.rpm'. 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 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 option
(see 'man mount') to the CD-ROM entry in /etc/fstab during package install, (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 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 (ISO9660) on CD-ROMs, which will greatly confuse users as they won't find
@ -564,23 +493,13 @@ Joliet, files not found).
4. Installing Wine for the user 4. Installing Wine for the user
The user will need to run a setup script before the first invocation of Wine. The user will need to run a wineprefixcreate before the first invocation
This script should: of Wine.
* Copy /etc/wine/wine.conf for user modification.
* Allow specification of the original windows installation to use A packager might provide a wrapper for wine to do that automatically,
(which modifies the copied wine.conf file). like if the WINEPREFIX directory (~/.wine) is not present.
* Create the windows directory structure (c:\windows, c:\windows\system,
c:\windows\Start Menu\Programs, c:\Program Files, c:\Desktop, etc.) Thats it.
* 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 AUTHORS
~~~~~~~ ~~~~~~~
@ -590,3 +509,4 @@ Updated in 2000 by Jeremy White <jwhite@codeweavers.com>
Updated in 2002 by Andreas Mohr <andi@rhlx01.fht-esslingen.de> 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 Tom Wickline <twickline2@triad.rr.com>
Updated in 2003 by Dimitrie O. Paun <dpaun@rogers.com> Updated in 2003 by Dimitrie O. Paun <dpaun@rogers.com>
Updated in 2004 by Marcus Meissner <marcus@jet.franken.de>