Orphaning Packages: audacious and dependencies

Michael Schwendt mschwendt at gmail.com
Sun Jun 7 09:04:23 UTC 2009


http://mschwendt.fedorapeople.org/audacious-2.0.1-0.1.fc10.src.rpm
http://mschwendt.fedorapeople.org/audacious-plugins-2.0.1-0.1.fc10.src.rpm

The included tarball is stripped for Fedora, to remove problematic
files. Builds have been tested on F10 only. F11 is next.

What will be needed is a maintainer for the -freeworld plugin packages.
It shall be easy to modify above -plugins package and put back the
original tarball, the required BR and configure options, and a
desktop file for the MIME types.

The API changes must be checked with every package that depends on
audacious-devel.

> Meanwhile I'm almost done with preparing packages for Audacious 2.
> Actually I have it running here already, but whereas I'm 99% done with
> the -plugins package I still need to examine/rediff the patches in the
> main package. It's not something I've done in one tiresome block as I've
> almost started from scratch, only keeping fragments of the cleaned-up
> 1.5.1 packages. Will publish them eventually prior to working on including
> them in Fedora.
> 
> Some random observations: 
> 
> There are API changes, which break external plugins, GVfs e.g. and header
> locations. At least audacious-plugin-fc needs an updated implementation.
> 
> There are patches that still need to be applied upstream.
> 
> There is stuff in the packages which I consider questionable.
> E.g. mp3/mpeg/wma related MIME types get removed from the main desktop
> file, but also WAV and Ogg, then a hidden desktop file is added in the
> -plugins package which readds the removed types although the needed
> plugins are not available in the Fedora packages due to legal reasons.
> The 3rd party packages could add such hidden desktop files. And actually
> the main player is useless without the plugins package, so why add a
> second hidden desktop file at all?
> 
> Audacious 1 and Audacious 2 cannot coexist, since only the executables
> have different names. I don't think it is worthwhile to create symlinks
> for the old executable names.




More information about the devel mailing list