Packaging guidelines for GStreamer ---------------------------------- Here are some guidelines for people trying to package GStreamer. VERSIONS -------- First of all, there are two concepts of version in GStreamer. The first is the source package version; it is either of the form x.y.z or x.y.z.n x is the major number, y is the minor number, z is the micro number, and n (if it exists) is the nano number. In the first case, it is an official release of GStreamer. In the second case, it is a cvs version tarball if n == 1, and a prerelease for the next version if n > 1. Source releases where y is even are considered "stable", and source releases where y is uneven are considered "unstable" or "development". This is similar to a lot of projects, including GLib and the kernel. The second version is an "interface" version, used in versioning tools, the library name, packages, GConf install paths, registry locations, and so on. It is of the form x.y Commonly, it is refered to as the "major/minor" number of GStreamer. In most cases it is the same as the one used in the source version; only when we are doing release candidates for a new major/minor source version do we manually force the major/minor to be the same as the one for the next new version. This is done to shake out bugs that can arise due to this change before we do an actual x.y.0 release. PARALLEL INSTALLABILITY ----------------------- Versions of GStreamer with a different "interface" or major/minor version are supposed to be parallel-installable. If they're not then it's considered to be a bug. There are parallel-installable versions from the 0.6 set and onwards. In practice, this means that - libraries contain the major/minor version in their name - plugins are installed in a major/minor-versioned directory - include headers are installed in separate directories - registry is saved in major/minor-versioned locations - major/minor-versioned tools are installed, together with versioned man pages - non-versioned front-end tools are also installed, that call the versioned ones, and only depend on glib and popt. So, all parts of GStreamer are parallel-installable, EXCEPT for the non-versioned tools and man pages. However, only one of these sets needs to be present, and preferably the latest source version of them. PACKAGING --------- To make packages of different major/minor versions parallel installable, the important part is to separate the package of the nonversioned tools and man pages, and make them usable for all the GStreamer library packages. We recommend putting the versioned binaries and man pages in the same package as the base GStreamer library. The base GStreamer library should require a version of the non-versioned tools, so that users can expect the non-versioned tools to be present in all cases, and our documentation agrees with the install. As for package names, we recommend the following system: - "gstreamer" as the base name should be used for the latest stable version of GStreamer. - "gstreamerxy" should be used for all other versions (older stable version, as well as current development version) As an example: - 0.7 is current development version, and 0.6 is latest stable version: "gstreamer" for 0.6 and "gstreamer07" for 0.7 - 0.8.0 gets released: "gstreamer06" for 0.6, "gstreamer07" is kept for 0.7, and "gstreamer" for 0.8, where: - the 0.8 "gstreamer" package can now obsolete the 0.7 package - the 0.6 "gstreamer06" package can obsolete previous "gstreamer" packages with lower version/release This ensures that users who just want the latest stable version of GStreamer can just install the "gstreamer"-named set of packages, while automatic tools can still upgrade cleanly, maintaining compatibility for applications requiring older versions. This base named should be used for all GStreamer packages; for example gstreamer07-plugins is a package of plugins to work with the gstreamer07 base library package. SPLITTING OF PLUGIN PACKAGES ---------------------------- Since GStreamer can depend on, but isn't forced to depend on, more than 40 additional libraries, choosing how to package these is a challenge compared to other projects. Three approaches have been used in the past. One was "one package per dependency library", so that users could choose exactly what functionality they want installed. A second one was "split according to functionality". This is more arbitrary. A third one, used by some distributors, is "put everything we want to ship in one big package". Packagers seem to agree that the first approach is too hard and users do not care this much about fine-grained control. We decided on a mix of 2) and 3); preferring to follow the base distribution's decision for the base -plugins package, then creating additional packages based on functionality. Plugins are put in -audio, -video, -dvd and -alsa packages. Also, some plugins are put in -extras- packages because they are distributed from a different location, are not as well maintained, have other issues, ... In the case of Fedora, for example, mp3 plugins are shipped in -extras-audio, and distributed on FreshRPMS or rpm.livna.org For Mandrake, for example, they would be shipped from PLF. Now, to make sure other packages can require functionality they need, virtual provides are added for plugin packages, combining the base gstreamer name with the name of the actual GStreamer plugin. Assuming 0.7, and the mad plugin, the package "gstreamer07-plugins-extra-audio" would virtual-provide "gstreamer07-mad". It would contain the file libgstmad.so in the correct directory. PACKAGING TIPS FOR RPMS ----------------------- * use a define for the base package name for all GStreamer spec files: %define gstreamer gstreamer07 * use a define for the major/minor version of the package: %define majorminor 0.7 This ensures you can easily migrate your spec files when a new major/minor version is released. * always use the correctly versioned gst-register-x.y tool in post scripts that install plugins. It helps to create a define for this as well: %define register %{_bindir}/gst-register-%{majorminor} > /dev/null 2>&1 * make each package that installs plugins have (pre) and (post) requires on the versioned register binary * make each package that installs plugins have a requires on the corresponding base plugins package * make sure that the nonversioned tools and man pages are put in a package that is named "gstreamer-tools" no matter what the major/minor version is. This way, the latest version of this package can be used for all previous major/minor packages. If you do not want this package twice, with different versions, then write your spec so that you don't package the tools for previous versions, and only for the latest version. * applications that require specific plugins to function should require the correct -plugins package, as well as any additional virtual provides they need to pull in. * stable releases can obsolete: the previous development releases to ensure they get removed when installing the new stable version.