1
________________________________________________
2
How to make good binary package(s) of MPlayer?
3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4
by Dominik 'Rathann' Mierzejewski
9
With the release of MPlayer 0.90pre9, all licensing issues have been
10
eliminated and all code is licensed under the GPL, which allows
11
independent packagers to create and distribute binary packages. At first,
12
this was discouraged by some of the developers, but the users' demand for
13
ready-to-use binary packages convinced some people to create them.
14
Unfortunately, many currently available packages are crippled, include
15
their own obsolete config files or are mispackaged in some other way. This
16
document aims to establish a common set of packaging guidelines so that
17
proper official binary packages for various Linux distributions and other
18
operating systems can be maintained.
23
Whenever you see "MUST", it means that following the mentioned guideline
24
is required. Whenever you see "SHOULD", it means that following the
25
guideline is highly recommended, but not required.
30
Due to MPlayer design, it is impossible to simply include all possible
31
features and enable or disable them at runtime. That is why packagers
32
SHOULD avoid "dependency hell" by retaining a reasonable, limited default
33
feature set. After some discussion with other developers, we agreed that
34
the following features MUST be included in any official binary package:
47
- libavcodec(internal)
48
- native codecs (libmpeg2/liba52/mp3lib)
49
- Vorbis Tremor codec(internal)
50
- RealPlayer codecs support
51
- Win32/VfW/DShow/QT codecs support
52
- XAnim codecs support
56
- FreeType fonts support
68
There is great demand for the GUI, so it SHOULD be included, but it MUST
69
come as a separate package (see Tips and Tricks for details).
71
Including other features, like LIVE.COM streaming or JACK support, is
72
acceptable. They SHOULD, however, be build-time configurable, with the
73
default build configuration containing the above set.
75
It seems there are some packages in the wild which lack included docs.
76
This is VERY BAD, as it forces users to look for outside support when most
77
of the common problems are easy to solve and are already described in the
78
docs, thus increasing the number of repeated posts in MPlayer mailing
79
lists. Binary packages MUST include both the man page and HTML
80
documentation. Translated versions SHOULD be included, even if your
81
package management system does not provide specific support for
84
Libavcodec MUST always be in the latest development version and it MUST
85
be linked statically into the mplayer binary, because MPlayer requires a
86
recent libavcodec snapshot. While some distributions provide FFmpeg
87
packages containing a shared libavcodec library, they are often based on the
88
last "release" version of FFmpeg, which is quite old and will usually not
89
function correctly with MPlayer.
94
In general, you SHOULD follow your distribution guidelines. For example,
95
for Red Hat and Fedora RPMs I am using FHS-compliant paths:
97
/etc/mplayer/ system-wide configs
99
/usr/lib/codecs/ binary codecs
100
/usr/share/doc/mplayer-version/ docs
101
/usr/share/man/man1/ man page
102
/usr/share/man/XX/man1/ translated man page
103
/usr/share/mplayer/font/ fonts
104
/usr/share/mplayer/Skin/ GUI skins
106
You MUSTN'T include the codecs.conf file in your package. It is useful
107
only for development purposes and often causes obscure problems for users.
110
One package or many packages?
111
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
112
Although it is tempting to simply provide a single all-in-one package,
113
I think it is best to split MPlayer into several packages. It may be
114
a little more troublesome for less clueful users, but it allows you to
115
install only what you need. This is the layout I am using for Red Hat and
118
mencoder contains MEncoder binary (mencoder)
119
mplayer contains MPlayer binary without GUI (mplayer),
120
config files, man pages and documentation;
121
required by mplayer-gui
122
mplayer-codecs-* contain binary codecs available from MPlayer's site
123
mplayer-font-* contain various bitmap fonts for OSD (obsolete)
124
mplayer-gui contains MPlayer binary with GUI (gmplayer);
125
contains default skin (Blue)
126
mplayer-skin-* contain various MPlayer GUI skins
127
mplayer-vidix contains VIDIX support library for MPlayer
128
mplayer-vidix-* contain VIDIX drivers for specific cards, one per package
130
There is no strict policy for now, just use your common sense.
135
While it is acceptable to provide packages optimized for specific CPUs,
136
you MUST provide at least one "lowest common denominator" package set
137
that will work on all CPUs. This means it MUST be configured with the
138
--enable-runtime-cpudetection option. Building for specific CPUs requires
139
disabling this option, but try to make sure that users cannot accidentally
140
install a package not suitable for their CPU. With RPMs, for example, this
141
is handled automatically, when building with the "--target arch" rpm option.
143
Compiler flags MUST be set to either configure-generated CFLAGS or something
144
as close to them as possible.
146
Users MUST be able to rebuild your source package without hand-editing on
147
any system with the same distribution installed. Remember to disable
148
(--disable-xxx) any optional features, because MPlayer's configure script
149
autodetects most of them. This ensures that binary package builds are
150
deterministic -- that is, provided they have at least the required
151
development packages installed, two different people using the same
152
distribution will get binaries with the same dependencies.
154
You SHOULD provide an option to rebuild the package with full debug
155
information enabled (by passing --enable-debug=3 to ./configure and
156
disabling any stripping of binaries and libs during the build process).
157
For example my source RPM can be rebuilt with a "--with debug" option, which
158
does just that, making it easier to supply gdb information along with any
159
bug reports, while retaining all benefits of using binary packages.
165
You MUST modify `mplayer -v` output so that it is clear that a user is
166
using your binary package, by patching version.h and modifying the version
167
string inside. Suggested convention is to include distribution name and,
168
possibly, the signature of the packager or the repository. For example:
171
MPlayer 1.0pre5-3.3.2 (C) 2000-2004 MPlayer Team
173
MPlayer 1.0pre5-Fedora-GS-3.3.2 (C) 2000-2004 MPlayer Team
174
MPlayer 1.0pre5-Mandrake-PLF-3.2.3 (C) 2000-2004 MPlayer Team
175
MPlayer 1.0pre5-Solaris-3.4.0 (C) 2000-2004 MPlayer Team
180
In my package layout, mplayer and mplayer-gui can be installed at the same
181
time, because they contain differently named binaries and there is no
182
conflict. The trick is to build MPlayer once with --enable-gui, rename the
183
resulting binary to "gmplayer" and then build it again, without GUI, but
184
keeping the rest of ./configure options the same.
186
To provide man pages for all MPlayer suite binaries (mplayer, gmplayer,
187
mencoder), you can use man-links instead of regular symbolic links.
188
Creating a mencoder man page linked to mplayer is as simple as:
190
echo ".so mplayer.1" >> mencoder.1
192
A similar trick can be used for "man gmplayer". This avoids problems with
193
gzipped man pages and symbolic links.
195
Newer Red Hat and Fedora distributions keep localized man pages encoded in
196
UTF-8. If your distribution does the same, make sure you convert MPlayer's
197
translated man pages to UTF-8 so that man mplayer works for locales other
added
removed
DOCS/tech/binary-packaging.txt
