Mercurial > mplayer.hg
annotate DOCS/tech/binary-packaging.txt @ 19382:7c6c205b88b6
trying to fix the reverting paragraph
if you dissagree, dont hesitate to revert this commit or flame, but at least we should not claim that svn cannot revert commits except by recommiting the old version
author | michael |
---|---|
date | Sun, 13 Aug 2006 22:14:32 +0000 |
parents | 9a5a62f480e6 |
children | e7cd9c08d1d9 |
rev | line source |
---|---|
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 | |
16950 | 40 - OSS |
14267 | 41 - tdfxfb |
42 - (c/x)vidix | |
43 - X11/Xvideo | |
44 | |
45 * codecs | |
46 - FAAD | |
47 - libavcodec(internal) | |
48 - native codecs (libmpeg2/liba52/mp3lib) | |
16949 | 49 - Vorbis Tremor codec(internal) |
14267 | 50 - RealPlayer codecs support |
51 - Win32/VfW/DShow/QT codecs support | |
52 - XAnim codecs support | |
53 | |
54 * general: | |
55 - default font | |
56 - FreeType fonts support | |
57 - HTML documentation | |
58 - large file support | |
59 - man page(s) | |
60 | |
61 * input/demuxers: | |
62 - DVD(mpdvdkit2) | |
63 - streaming | |
64 - Matroska(internal) | |
65 - (S)VCD | |
66 - tv(v4l/v4l2) | |
67 | |
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). | |
70 | |
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. | |
74 | |
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 | |
82 internationalization. | |
83 | |
16949 | 84 Libavcodec MUST always be in the latest development version and it MUST |
14268 | 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. | |
14267 | 90 |
91 | |
92 File locations | |
93 ~~~~~~~~~~~~~~ | |
94 In general, you SHOULD follow your distribution guidelines. For example, | |
14268 | 95 for Red Hat and Fedora RPMs I am using FHS-compliant paths: |
14267 | 96 |
97 /etc/mplayer/ system-wide configs | |
98 /usr/bin/ binaries | |
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 | |
17974
9a5a62f480e6
Rename the default GUI skins directory from 'Skin' to 'skins', keeping
diego
parents:
16950
diff
changeset
|
104 /usr/share/mplayer/skins/ GUI skins |
14267 | 105 |
16949 | 106 You MUSTN'T include the codecs.conf file in your package. It is useful |
14267 | 107 only for development purposes and often causes obscure problems for users. |
108 | |
109 | |
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 | |
14268 | 115 install only what you need. This is the layout I am using for Red Hat and |
14267 | 116 Fedora RPMs: |
117 | |
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); | |
16950 | 125 contains default skin (Blue) |
14267 | 126 mplayer-skin-* contain various MPlayer GUI skins |
14268 | 127 mplayer-vidix contains VIDIX support library for MPlayer |
128 mplayer-vidix-* contain VIDIX drivers for specific cards, one per package | |
14267 | 129 |
130 There is no strict policy for now, just use your common sense. | |
131 | |
132 | |
133 Compilation | |
134 ~~~~~~~~~~~ | |
135 While it is acceptable to provide packages optimized for specific CPUs, | |
136 you MUST provide at least one "lowest common denominator" package set | |
14268 | 137 that will work on all CPUs. This means it MUST be configured with the |
14267 | 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 | |
14268 | 141 is handled automatically, when building with the "--target arch" rpm option. |
14267 | 142 |
143 Compiler flags MUST be set to either configure-generated CFLAGS or something | |
144 as close to them as possible. | |
145 | |
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. | |
153 | |
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). | |
14268 | 157 For example my source RPM can be rebuilt with a "--with debug" option, which |
14267 | 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. | |
160 | |
161 | |
162 Modifications | |
163 ~~~~~~~~~~~~~ | |
164 | |
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: | |
169 | |
170 original: | |
171 MPlayer 1.0pre5-3.3.2 (C) 2000-2004 MPlayer Team | |
172 modified: | |
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 | |
176 | |
177 | |
178 Tips and tricks | |
179 ~~~~~~~~~~~~~~~ | |
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. | |
185 | |
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: | |
189 | |
190 echo ".so mplayer.1" >> mencoder.1 | |
191 | |
14268 | 192 A similar trick can be used for "man gmplayer". This avoids problems with |
14267 | 193 gzipped man pages and symbolic links. |
194 | |
14268 | 195 Newer Red Hat and Fedora distributions keep localized man pages encoded in |
14267 | 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 | |
198 than English. |