14267
|
1 ________________________________________________
|
|
2 How to make good binary package(s) of MPlayer?
|
|
3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
4 by Dominik 'Rathann' Mierzejewski
|
|
5
|
|
6 About this document
|
|
7 ~~~~~~~~~~~~~~~~~~~
|
|
8
|
|
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.
|
|
19
|
|
20
|
|
21 Conventions
|
|
22 ~~~~~~~~~~~
|
|
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.
|
|
26
|
|
27
|
|
28 Minimum feature set
|
|
29 ~~~~~~~~~~~~~~~~~~~
|
|
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:
|
|
35
|
|
36 * audio/video output
|
|
37 - fbdev
|
|
38 - JPEG/PNG/TGA
|
|
39 - (X)MGA
|
|
40 - OSS
|
|
41 - SDL
|
|
42 - tdfxfb
|
|
43 - (c/x)vidix
|
|
44 - X11/Xvideo
|
|
45
|
|
46 * codecs
|
|
47 - FAAD
|
|
48 - libavcodec(internal)
|
|
49 - native codecs (libmpeg2/liba52/mp3lib)
|
|
50 - Ogg Vorbis support
|
|
51 - RealPlayer codecs support
|
|
52 - Win32/VfW/DShow/QT codecs support
|
|
53 - XAnim codecs support
|
|
54
|
|
55 * general:
|
|
56 - default font
|
|
57 - FreeType fonts support
|
|
58 - HTML documentation
|
|
59 - large file support
|
|
60 - man page(s)
|
|
61
|
|
62 * input/demuxers:
|
|
63 - DVD(mpdvdkit2)
|
|
64 - streaming
|
|
65 - Matroska(internal)
|
|
66 - (S)VCD
|
|
67 - tv(v4l/v4l2)
|
|
68
|
|
69 There is great demand for the GUI, so it SHOULD be included, but it MUST
|
|
70 come as a separate package (see Tips and Tricks for details).
|
|
71
|
|
72 Including other features, like LIVE.COM streaming or JACK support, is
|
|
73 acceptable. They SHOULD, however, be build-time configurable, with the
|
|
74 default build configuration containing the above set.
|
|
75
|
|
76 It seems there are some packages in the wild which lack included docs.
|
|
77 This is VERY BAD, as it forces users to look for outside support when most
|
|
78 of the common problems are easy to solve and are already described in the
|
|
79 docs, thus increasing the number of repeated posts in MPlayer mailing
|
|
80 lists. Binary packages MUST include both the man page and HTML
|
|
81 documentation. Translated versions SHOULD be included, even if your
|
|
82 package management system does not provide specific support for
|
|
83 internationalization.
|
|
84
|
|
85 Libavcodec MUST always be in the latest development version and it SHOULD
|
|
86 be linked statically into mplayer binary, because MPlayer requires a
|
|
87 recent libavcodec snapshot. While some distributions provide ffmpeg
|
|
88 packages containing shared libavcodec library, they are often based on the
|
|
89 last "release" version of ffmpeg, which is quite old and will usually not
|
|
90 function with MPlayer.
|
|
91
|
|
92
|
|
93 File locations
|
|
94 ~~~~~~~~~~~~~~
|
|
95 In general, you SHOULD follow your distribution guidelines. For example,
|
|
96 for RedHat and Fedora RPMs I am using FHS-compliant paths:
|
|
97
|
|
98 /etc/mplayer/ system-wide configs
|
|
99 /usr/bin/ binaries
|
|
100 /usr/lib/codecs/ binary codecs
|
|
101 /usr/share/doc/mplayer-version/ docs
|
|
102 /usr/share/man/man1/ man page
|
|
103 /usr/share/man/XX/man1/ translated man page
|
|
104 /usr/share/mplayer/font/ fonts
|
|
105 /usr/share/mplayer/Skin/ GUI skins
|
|
106
|
|
107 You MUST never include the codecs.conf file in your package. It is useful
|
|
108 only for development purposes and often causes obscure problems for users.
|
|
109
|
|
110
|
|
111 One package or many packages?
|
|
112 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
113 Although it is tempting to simply provide a single all-in-one package,
|
|
114 I think it is best to split MPlayer into several packages. It may be
|
|
115 a little more troublesome for less clueful users, but it allows you to
|
|
116 install only what you need. This is the layout I am using for RedHat and
|
|
117 Fedora RPMs:
|
|
118
|
|
119 mencoder contains MEncoder binary (mencoder)
|
|
120 mplayer contains MPlayer binary without GUI (mplayer),
|
|
121 config files, man pages and documentation;
|
|
122 required by mplayer-gui
|
|
123 mplayer-codecs-* contain binary codecs available from MPlayer's site
|
|
124 mplayer-font-* contain various bitmap fonts for OSD (obsolete)
|
|
125 mplayer-gui contains MPlayer binary with GUI (gmplayer);
|
|
126 requires default skin package
|
|
127 mplayer-skin-* contain various MPlayer GUI skins
|
|
128 mplayer-vidix contains vidix support library for MPlayer
|
|
129 mplayer-vidix-* contain vidix drivers for specific cards, one per package
|
|
130
|
|
131 There is no strict policy for now, just use your common sense.
|
|
132
|
|
133
|
|
134 Compilation
|
|
135 ~~~~~~~~~~~
|
|
136 While it is acceptable to provide packages optimized for specific CPUs,
|
|
137 you MUST provide at least one "lowest common denominator" package set
|
|
138 that will work on all CPUs. This means it MUST be configured with
|
|
139 --enable-runtime-cpudetection option. Building for specific CPUs requires
|
|
140 disabling this option, but try to make sure that users cannot accidentally
|
|
141 install a package not suitable for their CPU. With RPMs, for example, this
|
|
142 is handled automatically, when building with "--target arch" rpm option.
|
|
143
|
|
144 Compiler flags MUST be set to either configure-generated CFLAGS or something
|
|
145 as close to them as possible.
|
|
146
|
|
147 Users MUST be able to rebuild your source package without hand-editing on
|
|
148 any system with the same distribution installed. Remember to disable
|
|
149 (--disable-xxx) any optional features, because MPlayer's configure script
|
|
150 autodetects most of them. This ensures that binary package builds are
|
|
151 deterministic -- that is, provided they have at least the required
|
|
152 development packages installed, two different people using the same
|
|
153 distribution will get binaries with the same dependencies.
|
|
154
|
|
155 You SHOULD provide an option to rebuild the package with full debug
|
|
156 information enabled (by passing --enable-debug=3 to ./configure and
|
|
157 disabling any stripping of binaries and libs during the build process).
|
|
158 For example my source RPM can be rebuilt with "--with debug" option, which
|
|
159 does just that, making it easier to supply gdb information along with any
|
|
160 bug reports, while retaining all benefits of using binary packages.
|
|
161
|
|
162
|
|
163 Modifications
|
|
164 ~~~~~~~~~~~~~
|
|
165
|
|
166 You MUST modify `mplayer -v` output so that it is clear that a user is
|
|
167 using your binary package, by patching version.h and modifying the version
|
|
168 string inside. Suggested convention is to include distribution name and,
|
|
169 possibly, the signature of the packager or the repository. For example:
|
|
170
|
|
171 original:
|
|
172 MPlayer 1.0pre5-3.3.2 (C) 2000-2004 MPlayer Team
|
|
173 modified:
|
|
174 MPlayer 1.0pre5-Fedora-GS-3.3.2 (C) 2000-2004 MPlayer Team
|
|
175 MPlayer 1.0pre5-Mandrake-PLF-3.2.3 (C) 2000-2004 MPlayer Team
|
|
176 MPlayer 1.0pre5-Solaris-3.4.0 (C) 2000-2004 MPlayer Team
|
|
177
|
|
178
|
|
179 Tips and tricks
|
|
180 ~~~~~~~~~~~~~~~
|
|
181 In my package layout, mplayer and mplayer-gui can be installed at the same
|
|
182 time, because they contain differently named binaries and there is no
|
|
183 conflict. The trick is to build MPlayer once with --enable-gui, rename the
|
|
184 resulting binary to "gmplayer" and then build it again, without GUI, but
|
|
185 keeping the rest of ./configure options the same.
|
|
186
|
|
187 To provide man pages for all MPlayer suite binaries (mplayer, gmplayer,
|
|
188 mencoder), you can use man-links instead of regular symbolic links.
|
|
189 Creating a mencoder man page linked to mplayer is as simple as:
|
|
190
|
|
191 echo ".so mplayer.1" >> mencoder.1
|
|
192
|
|
193 Similar trick can be used for "man gmplayer". This avoids problems with
|
|
194 gzipped man pages and symbolic links.
|
|
195
|
|
196 Newer RedHat and Fedora distributions keep localized man pages encoded in
|
|
197 UTF-8. If your distribution does the same, make sure you convert MPlayer's
|
|
198 translated man pages to UTF-8 so that man mplayer works for locales other
|
|
199 than English.
|