Amarok package maintenance
Amarok is one of the most used music players that uses the KDE libraries and framework. Its usage is not strictly connected to the KDE desktop itself, although some of its features are only available when running the KDE desktop. The maintenance of Amarok package isn't hard on its own, especially since upstream releases are scheduled in advance, and upstream is usually on time, and provides pre-releases for packagers only, so that eventual packaging bugs can be found before the actual official release. The only data that requires to be verified during every version bump is the availability of translation and documentation, that might vary from release to release. The easy way to get them is to run the following commands:
at this point, they can easily updated inside the ebuild, by defining the LANGS and LANGS_DOC variables at the top:
Amarok was designed to support different engines for audio decoding and playing, but after series 1.3, some of the unstable incomplete ones were dropped. Currently, the available engines are the xine engine, the default one and always built from ebuild (see the xine maintainer's guide), the Helix/RealPlayer engine, that can be enabled by the real USE flag on x86 architecture, the MAS and the NMM engines, that are strictly disabled because they are not in portage. Starting from version 1.4 (or rather its beta releases), Amarok requires that at least one stable engine is enabled, because users reported problems with experimental engine. The two stable engines that are available are xine-lib and Helix/RealPlayer. For this reason, Amarok ebuilds enable xine-lib engine forcefully, without an USE flag related to it, as it's the only one available for more than one platform (Helix, that would be available for PowerPC beside x86, is no more in portage, and wouldn't play mp3s anyway). As said, Helix Player is no more available in Portage, so we can only enable the related Amarok engine with RealPlayer, that is available only for x86 platform. One has not to be sidetracked by SUSE having an Helix engine available for AMD64 using RealPlayer, as they basically rewrote it to play files through commandline interface. Upstream does not endorse or support this approach. Due to a series of bugs in xine-lib, and some sanity checks applied by Amarok, since verison 1.4.2 of the player, it is required to have xine-lib 1.1.2 or later to play FLAC file (or a CVS snapshot just before it), and xine-lib 1.1.3 to play Shorten (SHN) files. Similar issues might come in the future, as Amarok reflects xine's bugs on a probably wider range of users. As well as different engines, Amarok can use also different database backends. The default (and mandatory) backend is SQLite 3; although MySQL and PostgreSQL backends can be turned off at build time to avoid unrequested dependencies, the SQLite backend cannot be switched off or removed. For some reasons, even if the SQLite copy used by Amarok is mostly pristine, using the system copy of SQLite, even with thread safety support enabled, produces copies of Amarok that can produce freezes on some systems. For this reason, the support for system SQLite use has been deemed unsafe and will not be used. Other database backends that can be used are MySQL and PostgreSQL. Both require user intervention to be set up, there's no way to configure them directly in ebuilds. As a full-fledged media player, Amarok also provides support for transferring songs to and from media devices, like mp3 players and similars. Its architecture allows to build plugins for special devices on request, which requires adding more USE flags to the ebuild to handle new media device plugins from release to release. Currently the supported media devices from the ebuild are the generic USB Mass Storage (requiring no dependencies), the iPod devices (using media-libs/libgpod), the IFP-based devices, early iRivers (using libifp), and the Nomad devices (using libnjb). MTP-based media devices are supported by Amarok using libmtp since version 1.4.2 onward, but the support is only present in ebuilds since version 1.4.4 onward, because precedently noone tested its support. Rio Karma support is present in Amarok since version 1.4.4, but it requires packages currently not in portage to work (and one of them is a Linux kernel module).
Since version 1.4, Amarok ebuild requires dev-lang/ruby forcefully; this is upon request by upstream, as the lyrics retrieval support, and the scoring and rating algorithms are now implemented as Ruby scripts. Then in version 1.4.1 also the last.fm proxy support, to play last.fm streams, was implemented this way, and the same applies for DAAP support in version 1.4.2. For this reason, ruby is by all means a mandatory required dependency. Since version 1.4.4-r4 onward, Amarok depends on www-servers/mongrel; since version 1.4.5, this dependency is optional over daap USE flag. The reason for this is that before that revision it installed its own copy of mongrel, which would have been fine until mongrel was not in portage, but might be a security breach now that mongrel is in portage, as the extensions might be using the wrong libhttp1.so library. For this reason the internal copy of mongrel is removed after installation (the build time for that is risible) and the external copy of mongrel is used. Note that older versions block mongrel so that they cannot be installed together with it for safety. As of version 1.4.5-r2, a new USE flag was added to Amarok: python. This flag is used to add a dependency over dev-python/PyQt, or remove the Web Control script. This flag was needed because the Web Control script is (oddly) written in Python and uses PyQt for the interface. No actual build-time Python support is needed to build Amarok anyway. Amarok supported for a long time the tag lookup through Musicbrainz by using the tunepimp library. Unfortunately that library had different versions with different APIs: 0.3, 0.4, 0.5, and each of them is incompatible with previous. Since version 1.4.2, Amarok supports the libtunepimp API 0.5, that is the only one available in portage for security reason (older versions had multiple security bugs, fixed by upstream only in 0.5 series), but it used to be buggy up to 1.4.4 release (Amarok was not properly cleaning up in case an entry wasn't found during a timeout), and up to version 0.5.1, libtunepimp crashed when being used on some types of files (WMA or FLAC). The issues are resolved as of 1.4.4-r3, and that version has the musicbrainz USE flag available once again. As upstream often considers the releases just some "SVN snapshots", many users got used to simply use the SVN version of Amarok on a daily basis. To make more friendly building from Subversion, they also provide an amarok-svn script that takes care of checking out the sources for the user and of compiling it with the correct options. As this solution does not go along well with Gentoo, many users developed their amarok-svn ebuild, that fetches the sources from KDE's repository and compile it with USE flags as options. Some of these ebuilds were published, and advertised on Amarok's wiki and on the #amarok channel on Freenode. The problems started when these ebuilds started skipping calls to kde.eclass to work around errors in themselves, and often ended up out of sync with the official ebuild, installing in the wrong prefix or behaving inconsistently. To overcome this issue (that was wasting a lot of the maintainer's time), at the end of December 2006, a Live SVN ebuild was added with the name amarok-1.4.9999. This ebuild is unsupported, albeit kept in sync and fixed when needed, so that users won't end up to break their systems anymore, and come to Gentoo developers complaining about it, because of ebuilds entirely out of sync. Being hardmasked and without keywords, it might, for instance, depend on a newer version of a dependency that is not yet in the tree. Amarok has a modular structure with plugins, that allows the user to add extra features, some of which are embedded in upstream sources, so that new core functionalities are enabled when the proper packages are available. The main examples are transKode (media-sound/transkode) that allows to transcode music from one format to another on-the-fly when loading music to a portable media player device, and moodbar (media-sound/moodbar) that replaces the feature previously provided by exscalibar (that was unmaintained upstream and full of bugs). These packages might have an amarok USE flag to enable the support for the scripts features of Amarok, while Amarok should not have an USE flag for them to avoid cluttering. The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. |
|
