________________________________________________ How to make good binary package(s) of MPlayer? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by Dominik 'Rathann' MierzejewskiAbout this document~~~~~~~~~~~~~~~~~~~With the release of MPlayer 0.90pre9, all licensing issues have beeneliminated and all code is licensed under the GPL, which allowsindependent packagers to create and distribute binary packages. At first,this was discouraged by some of the developers, but the users' demand forready-to-use binary packages convinced some people to create them.Unfortunately, many currently available packages are crippled, includetheir own obsolete config files or are mispackaged in some other way. Thisdocument aims to establish a common set of packaging guidelines so thatproper official binary packages for various Linux distributions and otheroperating systems can be maintained.Conventions~~~~~~~~~~~Whenever you see "MUST", it means that following the mentioned guidelineis required. Whenever you see "SHOULD", it means that following theguideline is highly recommended, but not required.Minimum feature set~~~~~~~~~~~~~~~~~~~Due to MPlayer design, it is impossible to simply include all possiblefeatures and enable or disable them at runtime. That is why packagersSHOULD avoid "dependency hell" by retaining a reasonable, limited defaultfeature set. After some discussion with other developers, we agreed thatthe following features MUST be included in any official binary package:* audio/video output - fbdev - JPEG/PNG/TGA - (X)MGA - OSS - tdfxfb - (c/x)vidix - X11/Xvideo* codecs - FAAD(internal) - libavcodec(internal) - native codecs (libmpeg2/liba52/mp3lib) - Vorbis Tremor codec(internal) - RealPlayer codecs support (*) - Win32/VfW/DShow/QT codecs support (*) - XAnim codecs support (*)* general: - default font - FreeType fonts support - HTML documentation - large file support - man page(s)* input/demuxers: - DVD(mpdvdkit2) - streaming - Matroska(internal) - (S)VCD - tv(v4l/v4l2)(*) if available for your OS/hardwareThere is great demand for the GUI, so it SHOULD be included, but it MUSTcome as a separate package (see Tips and Tricks for details).Including other features, like LIVE.COM streaming or JACK support, isacceptable. They SHOULD, however, be build-time configurable, with thedefault build configuration containing the above set.It seems there are some packages in the wild which lack included docs.This is VERY BAD, as it forces users to look for outside support when mostof the common problems are easy to solve and are already described in thedocs, thus increasing the number of repeated posts in MPlayer mailinglists. Binary packages MUST include both the man page and HTMLdocumentation. Translated versions SHOULD be included, even if yourpackage management system does not provide specific support forinternationalization.Libavcodec MUST always be in the latest development version and it SHOULDbe linked statically into the mplayer binary, because MPlayer requires arecent libavcodec snapshot. It is acceptable to use a shared (again, recent)version of libavcodec, but you must be aware that this disables some ofMPlayer's functions (for example, some postprocessing filters) and sacrificesspeed.Support for binary codecs SHOULD be present to the extent that the combinationof operating system and CPU architecture permits, but it MUST NOT result in ahard dependency on a binary codecs package. MPlayer is fully functional withoutexternal binary codecs. If you package binary codecs yourself, package theessential codecs package, not the all codecs package.Bitmap fonts are deprecated, don't package them. Use scalable (Type1/TrueType)fonts instead.File locations~~~~~~~~~~~~~~In general, you SHOULD follow your distribution guidelines. For example,for Red Hat and Fedora RPMs I am using FHS-compliant paths:/etc/mplayer/ system-wide configs/usr/bin/ binaries/usr/lib/codecs/ binary codecs/usr/share/doc/mplayer-version/ docs/usr/share/man/man1/ man page/usr/share/man/XX/man1/ translated man page/usr/share/mplayer/font/ fonts/usr/share/mplayer/skins/ GUI skinsYou MUST NOT include the codecs.conf file in your package. It is usefulonly for development purposes and often causes obscure problems for users.Please avoid using the deprecated paths for binary codecs (/usr/lib/win32/)and skins (/usr/share/mplayer/Skin/).One package or many packages?~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Although it is tempting to simply provide a single all-in-one package,I think it is best to split MPlayer into several packages. It may bea little more troublesome for less clueful users, but it allows you toinstall only what you need. This is the layout I am using for Red Hat andFedora RPMs:mencoder contains MEncoder binary (mencoder)mplayer contains MPlayer binary without GUI (mplayer), config files, man pages and documentation; required by mplayer-guimplayer-codecs-* contain binary codecs available from MPlayer's sitemplayer-font-* contain various bitmap fonts for OSD (obsolete)mplayer-gui contains MPlayer binary with GUI (gmplayer); contains default skin (Blue)mplayer-skin-* contain various MPlayer GUI skinsmplayer-vidix contains VIDIX support library for MPlayermplayer-vidix-* contain VIDIX drivers for specific cards, one per packageThere is no strict policy for now, just use your common sense.Compilation~~~~~~~~~~~While it is acceptable to provide packages optimized for specific CPUs,you MUST provide at least one "lowest common denominator" package setthat will work on all CPUs. This means it MUST be configured with the--enable-runtime-cpudetection option. Building for specific CPUs requiresdisabling this option, but try to make sure that users cannot accidentallyinstall a package not suitable for their CPU. With RPMs, for example, thisis handled automatically, when building with the "--target arch" rpm option.Compiler flags MUST be set to either configure-generated CFLAGS or somethingas close to them as possible.Users MUST be able to rebuild your source package without hand-editing onany system with the same distribution installed. Remember to disable(--disable-xxx) any optional features, because MPlayer's configure scriptautodetects most of them. This ensures that binary package builds aredeterministic -- that is, provided they have at least the requireddevelopment packages installed, two different people using the samedistribution will get binaries with the same dependencies.You SHOULD provide an option to rebuild the package with full debuginformation enabled (by passing --enable-debug=3 to ./configure anddisabling any stripping of binaries and libs during the build process).For example my source RPM can be rebuilt with a "--with debug" option, whichdoes just that, making it easier to supply gdb information along with anybug reports, while retaining all benefits of using binary packages.Modifications~~~~~~~~~~~~~You MUST modify `mplayer -v` output so that it is clear that a user isusing your binary package, by patching version.h and modifying the versionstring inside. Suggested convention is to include distribution name and,possibly, the signature of the packager or the repository. For example:original: MPlayer 1.0pre5-3.3.2 (C) 2000-2004 MPlayer Teammodified: MPlayer 1.0pre5-Fedora-GS-3.3.2 (C) 2000-2004 MPlayer Team MPlayer 1.0pre5-Mandrake-PLF-3.2.3 (C) 2000-2004 MPlayer Team MPlayer 1.0pre5-Solaris-3.4.0 (C) 2000-2004 MPlayer TeamIf you patch MPlayer, send your patches to us! We will try to integrate them.Furthermore, we're often able to come up with a cleaner or more generalsolution to your problem.If you have modified configuration files or similar, please patch the officialone instead of copying it into your package. This way you will automaticallypick up changes we make to it.Do not override video and audio output selection in the system-wide configfile. MPlayer will try to pick the best VO and AO itself and fall backgracefully. If you want to give priority to some AO, add a comma at the endof the line so that MPlayer can still fall back on others, for example:ao=alsa,Tips and tricks~~~~~~~~~~~~~~~In my package layout, mplayer and mplayer-gui can be installed at the sametime, because they contain differently named binaries and there is noconflict. The trick is to build MPlayer once with --enable-gui, rename theresulting binary to "gmplayer" and then build it again, without GUI, butkeeping the rest of ./configure options the same.To provide man pages for all MPlayer suite binaries (mplayer, gmplayer,mencoder), you can use man-links instead of regular symbolic links.Creating a mencoder man page linked to mplayer is as simple as: echo ".so mplayer.1" >> mencoder.1A similar trick can be used for "man gmplayer". This avoids problems withgzipped man pages and symbolic links.Newer Red Hat and Fedora distributions keep localized man pages encoded inUTF-8. If your distribution does the same, make sure you convert MPlayer'stranslated man pages to UTF-8 so that man mplayer works for locales otherthan English.